composer module | config command always returns changed

137 views
Skip to first unread message

Darren S.

unread,
May 31, 2016, 3:20:45 PM5/31/16
to ansible...@googlegroups.com
OS X 10.10.5
Python 2.7.11
Ansible 2.0.2.0
remote: Ubuntu 14.04.4 LTS
remote: Python 2.7.6
remote: PHP 5.5.9
remote: Composer version 1.2-dev

I notice in a play with the composer module that every invocation of
command=config to configure a certain key returns 'changed' status. Is
this the expected outcome?

Repeatedly executing this module returns 'changed' status each time:

$ ansible example.net -m composer -a 'command=config
arguments="vendor-dir Vendor" working_dir=/var/www/myapp' -bv
example.net | SUCCESS => {
"changed": true,
"msg": "Running composer as root/super user is highly discouraged
as packages, plugins and scripts cannot always be trusted"
}

$ ansible example.net -m composer -a 'command=config
arguments="vendor-dir Vendor" working_dir=/var/www/myapp' -bv
example.net | SUCCESS => {
"changed": true,
"msg": "Running composer as root/super user is highly discouraged
as packages, plugins and scripts cannot always be trusted"
}



The following tasks are used in this play, and each complete fine with
only the 'command=config' returning changed each time:

- name: composer | select cake-resque
composer: command=require arguments='kamisama/cake-resque:4.1.2'
working_dir={{ app_path }}

- name: composer | configure vendor-dir
composer: command=config arguments='vendor-dir Vendor'
working_dir={{ app_path }}

- name: composer | install something
composer: command=install working_dir={{ app_path }}


I can verify that the composer.json file in the working directory has
the following contents at the end of every run:

{
"require": {
"kamisama/cake-resque": "4.1.2"
},
"config": {
"vendor-dir": "Vendor"
}
}

Is there anything that can prevent 'changed' status on any run of the
task after the first?

--
Darren Spruell
phatb...@gmail.com

Johannes Kastl

unread,
May 31, 2016, 3:41:33 PM5/31/16
to ansible...@googlegroups.com
On 31.05.16 21:20 Darren S. wrote:

> Is there anything that can prevent 'changed' status on any run of the
> task after the first?

If it is intended that the module does not do this by itself, there is
always 'changed_when:'...
https://docs.ansible.com/ansible/playbooks_error_handling.html#overriding-the-changed-result

Johannes


signature.asc
Reply all
Reply to author
Forward
0 new messages