# variables in "--check" mode **URL:** \ **Category:** Ansible Project\ **Created:** [May 22, 2014, 3:20pm UTC](https://forum.ansible.com/t/variables-in-check-mode/15306 "2014-05-22T15:20:43Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![marc.petrivelli](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/marc.petrivelli/32/3773_2.png) [@marc.petrivelli](https://forum.ansible.com/u/marc.petrivelli)\ **Post date:** [May 22, 2014, 3:20pm UTC](https://forum.ansible.com/t/variables-in-check-mode/15306/1 "2014-05-22T15:20:43Z")
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. 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. I suggest changing the ansible --check mode to not evaluate those variables, in the when clause, normally brought into scope using register. Does anyone else have this problem? Did you use another work around? Do you like my idea of selectively evaluating variables that are “registered”? ---
**Author:** ![James\_Cammarata](https://avatars.discourse-cdn.com/v4/letter/j/7c8e57/32.png) [@James\_Cammarata](https://forum.ansible.com/u/James_Cammarata)\ **Post date:** [May 22, 2014, 4:00pm UTC](https://forum.ansible.com/t/variables-in-check-mode/15306/2 "2014-05-22T16:00:48Z")
I believe you’d want to check whether the registered variable (or member of the variable) is defined, as follows (assuming you registered a variable named result): when: ‘“foo” in result and result.foo != “something”’ This way, you can prevent undefined errors and the task would just be skipped. ---
**Author:** ![Tomasz\_Kontusz](https://avatars.discourse-cdn.com/v4/letter/t/bc79bd/32.png) [@Tomasz\_Kontusz](https://forum.ansible.com/u/Tomasz_Kontusz)\ **Post date:** [May 22, 2014, 5:20pm UTC](https://forum.ansible.com/t/variables-in-check-mode/15306/3 "2014-05-22T17:20:20Z")
> 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 :-)). ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [May 23, 2014, 12:29pm UTC](https://forum.ansible.com/t/variables-in-check-mode/15306/4 "2014-05-23T12:29:16Z")
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 🙂 ---
**Author:** ![marc.petrivelli](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/marc.petrivelli/32/3773_2.png) [@marc.petrivelli](https://forum.ansible.com/u/marc.petrivelli)\ **Post date:** [May 23, 2014, 3:42pm UTC](https://forum.ansible.com/t/variables-in-check-mode/15306/5 "2014-05-23T15:42:43Z")
Thanks for all the replies. I was not aware of the always\_run feature ([http://docs.ansible.com/playbooks\_checkmode.html](http://docs.ansible.com/playbooks_checkmode.html)) so that answers my question. Thank you. Also, @laserllama nice meeting you at AnsibleFest this week ---
**Author:** ![Tomasz\_Kontusz](https://avatars.discourse-cdn.com/v4/letter/t/bc79bd/32.png) [@Tomasz\_Kontusz](https://forum.ansible.com/u/Tomasz_Kontusz)\ **Post date:** [May 23, 2014, 7:19pm UTC](https://forum.ansible.com/t/variables-in-check-mode/15306/6 "2014-05-23T19:19:48Z")
> 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 🙂 Right, a variable like that wouldn't make anything new possible, it's just that I recall I wanted it for something. I'll note any use-cases if I run into them again (my memory is not too good with things I had gotten around anyway...).