On 22.05.2014 17:20, Marc Petrivelli wrote:
Variables that are brought into scope through the "register: var" when a
task is executed are not available when a playbook is run with the --check
mode.
That depends on the task - if a given module supports check-mode (most
of the ones bundled with Ansible do) it will give you *some* information.
Tasks using modules that do not support check mode are skipped by
default, so you'd need a workaround
The work-around I have been using is to put defaults (for all those
variables that will eventually be brought into scope using register) using
set_fact or group_vars/all or an included var file.
One way to work around it for modules that don't support check mode
(like command/shell, which can't do it for obvious reasons :-)) is to
have a data-gathering command with "always_run: yes", and then use that
to decide if the target command should be run.
For example:
- name: Get Jenkins's plugins
shell: jenkins-cli -s {{ jenkins.url }} list-plugins | cut -f 1 -d ' '
register: installed_plugins
changed_when: False
always_run: yes # This gets run even in check mode, as it's safe to
read a list of plugins
- name: Install missing plugins
shell: jenkins-cli -s {{ jenkins.url }} install-plugin -deploy {{ item }}
with_items: jenkins.plugins
when: item not in installed_plugins.stdout_lines
I suggest changing the ansible --check mode to not evaluate those
variables, in the when clause, normally brought into scope using register.
That sounds like a pretty confusing behavior, and it would break a lot
of existing plays.
Does anyone else have this problem? Did you use another work around? Do
you like my idea of selectively evaluating variables that are "registered"?
I did have this problem, and I still would sometimes like to have a
variable telling me if I'm in check mode (I know I can create one with
set_fact and always_run, but it's an ugly hack).
The only real workaround that won't make your --check runs useless is
splitting tasks into probing the system part, and changing the system
part (or writing modules that do this :-)).
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/537E31D4.4040207%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
