有條件的時候

與Ansible混淆爲什麼會發生這種情況。看來布爾人在沒有非常明確的情況下工作不正常。我不知道有沒有其他方式set_fact沒有使用Jinja2語法，感覺它可能是罪魁禍首。任何人都可以闡明它嗎？有條件的時候

- hosts: 127.0.0.1 
    connection: local 
    tasks: 
    - set_fact: 
     im_defined: "something" 
     im_false: "{{1 == 2}}" 

    - name: this should be skipped 
     debug: msg="SHOULD NOT SEE THIS MESSAGE! im_defined={{im_defined}} im_false={{im_false}}" 
     when: im_defined is defined and im_false

> ansible-playbook ansible-test.yml 

PLAY [127.0.0.1] ************************************************************** 

GATHERING FACTS *************************************************************** 
ok: [127.0.0.1] 

TASK: [set_fact ] ************************************************************* 
ok: [127.0.0.1] 

TASK: [this should be skipped] ************************************************ 
ok: [127.0.0.1] => { 
    "msg": "SHOULD NOT SEE THIS MESSAGE! im_defined=something im_false=False" 
} 

PLAY RECAP ******************************************************************** 
127.0.0.1     : ok=3 changed=0 unreachable=0 failed=0

看來，如果我改變當閱讀：

when: im_defined is defined and im_false == True

它按預期工作：

TASK: [this should be skipped] ************************************************ 
skipping: [127.0.0.1]

來源

2015-11-25 John Culviner

這背後的原因是，你的事實im_false實際上是一個字符串，而不是布爾值。

我測試了一下，im_false == True和im_false == False在這裏有相同的結果，所以我想它真的檢查它是否真實，而不是Truthy。

正確的檢查方法是用一個轉換過濾器：

when: im_defined is defined and im_false|bool

另見this bug report。

來源

2015-11-26 03:12:09 udondan

真棒，我想這可能是這樣的，但我不能把它放在手指上。希望有一種方法可以評估除jinja2之外的變量，並且我們不會讓字符串彈出......感嘆 –

有條件的時候

回答

相關問題