always_run is there, yes, but ultimately, check mode (dry run) is kind of a configuration management thing, and can get difficult in more step-wise application deployment or orchestration tasks.
I agree we're not going to make a behavior change to variable evaluation in check mode. I'm unclear on why we need a variable to indicate whether we are in check mode when always_run can be used for data gathering commands. It's not a workaround, it's a feature :) On Thu, May 22, 2014 at 1:20 PM, Tomasz Kontusz <[email protected]>wrote: > 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. > -- 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/CA%2BnsWgxHEaXrPiYPJAv4Cs%3D%3DgewcWB-y72e-hTaF3FMUJcJVLQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
