The yum task succeeded. It's the subsequent fail that is failing.  You can
make any other module +fail react in the same way:

- file: path=/var/tmp/i_do_not_exist_yet state=directory
- stat:
      path: /var/tmp/i_do_not_exist_yet
      register: file

    - fail:
        msg: "File i_do_not_exist_yet doesn't exist!"
      when: file.stat.exists == False

As flowerysong says, --check means, do not make any changes to the system.
So you cannot run ansible in check-mode and then expect an assertion that a
change was made to succeed.  Similarly, you cannot expect that running a
second task which depends on the first task to have changed the system in
some way to succeed in check-mode because the change will not have been
made to the system.

-Toshio

On Thu, May 10, 2018, 10:56 PM js.a <sjefer...@gmail.com> wrote:

> @flowerysong
>
> The point is, a CI tool such as Travis, Tower... will report error on that
> task, but actually there is no error at all (normal running). In addition,
> package installing task is just 0,5% of the whole deployment project and
> thinking deeper, every task does changes on the systems. Many ansible other
> modules I have used do work in --check mode, except package manager which I
> am reporting here.
>
> ---------------------------------------
>
> Em quinta-feira, 10 de maio de 2018 02:06:38 UTC-3, flowerysong escreveu:
>>
>> On Thursday, May 10, 2018 at 12:11:02 AM UTC-4, js.a wrote:
>>>
>>> Hello guys.
>>>
>>> I'm here to bring an issue with Ansible dry-run (--check) mode. I have
>>> been facing a curious situation where package installation made using
>>> Playbooks and run in a dry-run mode is not working as expected. Using
>>> register+debug module it's possible to see that the package has been
>>> successfully installed, but when I try to use that installed package in
>>> later task, Ansible fails.
>>>
>>> *My Playbook:*
>>>
>>> ---
>>> - hosts: logging
>>>   become: yes
>>>
>>>   tasks:
>>>     - name: Setting up EPEL
>>>       yum: name=epel-release state=present
>>>       register: inst
>>>     - debug: var=inst
>>>
>>>     - name: Checking installation
>>>       stat:
>>>         path: /etc/yum.repos.d/epel.repo
>>>       register: file
>>>
>>>     - fail:
>>>         msg: "File epel.repo doesn't exist!"
>>>       when: file.stat.exists == False
>>>
>>> *Result:*
>>>
>>> [root@c7 projX]# ansible-playbook -i inventory epel.yml --check
>>>
>>> PLAY [logging]
>>> ***************************************************************************
>>>
>>> TASK [Gathering Facts]
>>> *******************************************************************
>>> ok: [192.168.52.20]
>>>
>>> TASK [Setting up EPEL]
>>> *******************************************************************
>>> changed: [192.168.52.20]
>>>
>>> TASK [debug]
>>> *****************************************************************************
>>> ok: [192.168.52.20] => {
>>>     "inst": {
>>>         "changed": true,
>>>         "changes": {
>>>             "installed": [
>>>                 "epel-release"
>>>             ]
>>>         },
>>>         "failed": false,
>>>         "results": []
>>>     }
>>> }
>>>
>>> TASK [Checking installation]
>>> *************************************************************
>>> ok: [192.168.52.20]
>>>
>>> TASK [fail]
>>> ******************************************************************************
>>> fatal: [192.168.52.20]: FAILED! => {"changed": false, "msg": *"File
>>> epel.repo doesn't exist!"*}
>>>
>>> PLAY RECAP
>>> *******************************************************************************
>>> 192.168.52.20              : ok=4    changed=1    unreachable=0
>>> failed=1
>>>
>>>
>>> ---------------------------------------------------------------------------
>>>
>>> If I take '--check' for dry-run out of the command it does work, but
>>> it's not the best approach for me once I'm planning to put this "checking
>>> task" in a CI software to "automate the automation".
>>>
>>> My question is: is there any specific reason for that case (package
>>> installation) not to work with --check parameter? I've done further tests
>>> using Ubuntu and the Ansible's apt module but the same problem comes up.
>>>
>>
>> The whole point of check mode is that it doesn't make changes to the
>> system. If you want things to change (e.g. packages to install), don't run
>> in check mode.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ansible-project+unsubscr...@googlegroups.com.
> To post to this group, send email to ansible-project@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/19f62a98-3ae0-4515-9da1-8058a7805dba%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/19f62a98-3ae0-4515-9da1-8058a7805dba%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/CAPrnkaSCcJKu0uHJSqoyy_1ur6QzO5qibbKEL6cGYE8NSnpRAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to