# ansible version available as fact? **URL:** \ **Category:** Ansible Project\ **Created:** [April 11, 2014, 8:33pm UTC](https://forum.ansible.com/t/ansible-version-available-as-fact/15002 "2014-04-11T20:33:37Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Bryan\_Larsen](https://avatars.discourse-cdn.com/v4/letter/b/9de053/32.png) [@Bryan\_Larsen](https://forum.ansible.com/u/Bryan_Larsen)\ **Post date:** [April 11, 2014, 8:33pm UTC](https://forum.ansible.com/t/ansible-version-available-as-fact/15002/1 "2014-04-11T20:33:37Z")
I have a task that works on devel but not on 1.5.4. I assume it’s because of [https://github.com/ansible/ansible/commit/2a976a](https://github.com/ansible/ansible/commit/2a976a) - authorized\_key: user={{ item|basename }} key=“{{ lookup(‘file’, item) }}” with\_fileglob: - “…/…/…/…/keys/\*” We have ansible installed on all our production machines so we can do `-c local` deploys. I don’t want to upgrade those machines off of a “stable” version – if we’ve gotten far enough to run a `-c local`, at least some of the keys have been installed and we can skip the step. So I figured I’d just gate the task on ansible\_version or some such. However, there doesn’t appear to be such a variable, and I can’t find anything like that in -m setup. Is there some way of figuring out if we’re running 1.5 or 1.6 or later and using that in a task? Alternatively, is there a way of making my task work on 1.5? It worked on 1.2 and 1.3 (with a different path). thanks, Bryan ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [April 12, 2014, 1:15am UTC](https://forum.ansible.com/t/ansible-version-available-as-fact/15002/2 "2014-04-12T01:15:50Z")
Not quite yet. Have a look at [https://github.com/ansible/ansible/pull/6619](https://github.com/ansible/ansible/pull/6619) ---
**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\ **Post date:** [April 12, 2014, 8:36am UTC](https://forum.ansible.com/t/ansible-version-available-as-fact/15002/3 "2014-04-12T08:36:42Z")
​For now I guess you could work around with a pipe lookup running ansible --version​ ​In the mean time also [https://github.com/ansible/ansible/pull/6835](https://github.com/ansible/ansible/pull/6835) was merged, ​which gives you a version\_compare filter.    Serge ---
**Author:** ![Bryan\_Larsen](https://avatars.discourse-cdn.com/v4/letter/b/9de053/32.png) [@Bryan\_Larsen](https://forum.ansible.com/u/Bryan_Larsen)\ **Post date:** [April 21, 2014, 8:32pm UTC](https://forum.ansible.com/t/ansible-version-available-as-fact/15002/4 "2014-04-21T20:32:05Z")
I’ve got a role that works in 1.6 but crashes in 1.5. (My guess is that this fixes it: [https://github.com/ansible/ansible/commit/2a976a](https://github.com/ansible/ansible/commit/2a976a)) The crashing task is this: - authorized\_key: user={{ item|basename }} key=“{{ lookup(‘file’, item) }}” with\_fileglob: - “…/…/…/…/keys/\*” The role is one that I’m happy running manually for now, so I thought I’d gate it with something like: roles: - { role: ‘users’, when: ‘ansible\_version is defined’ } (this assumes [https://github.com/ansible/ansible/pull/6619](https://github.com/ansible/ansible/pull/6619) will land soon. For now, I’m just using -e) This skips the role, but it’s still being parsed and crashing ansible. Suggestions? ---
**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:** [April 21, 2014, 11:23pm UTC](https://forum.ansible.com/t/ansible-version-available-as-fact/15002/5 "2014-04-21T23:23:48Z")
If you would ever like to report a crash, including the “result” of the crash is needed to understand the context. Can you please paste the result you are receiving? ---
**Author:** ![Bryan\_Larsen](https://avatars.discourse-cdn.com/v4/letter/b/9de053/32.png) [@Bryan\_Larsen](https://forum.ansible.com/u/Bryan_Larsen)\ **Post date:** [April 22, 2014, 3:23pm UTC](https://forum.ansible.com/t/ansible-version-available-as-fact/15002/6 "2014-04-22T15:23:38Z")
I’m not sure why you want the backtrace; it’s already fixed in 1.6 by [https://github.com/ansible/ansible/commit/2a976a](https://github.com/ansible/ansible/commit/2a976a). I’ve attached the backtrace at the end of this email. The actual crash is not my concern. There are several different ways that you can crash ansible on skipped roles. Another way to do it is via with\_sequence: start=1 end={{ numFoo }} where numFoo is 0. That obviously should be an error when the task is run. What is surprising that ansible still crashes with “can’t count backwards” even if you tell it to skip the role containing the task: - { role: ‘foo’, when: ‘numFoo \> 0’ } This can be worked around through judicious use of the default filter. It’s just annoying. My original email in this thread outlined a situation where I couldn’t find a workaround, and asks for one. I can run ansible 1.6 locally, but I need my playbook to be compatible with 1.5. It’s OK if it skips problematic plays. thanks, Bryan ---
**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:** [April 23, 2014, 1:08pm UTC](https://forum.ansible.com/t/ansible-version-available-as-fact/15002/7 "2014-04-23T13:08:24Z")
> If you would ever like to report a crash, including the "result" of the > > > crash is > > needed to understand the context. > > > Can you please paste the result you are receiving? > > I'm not sure why you want the backtrace; it's already fixed in 1.6 by > [https://github.com/ansible/ansible/commit/2a976a](https://github.com/ansible/ansible/commit/2a976a). I've attached the > backtrace at the end of this email. It's entirely because you send an email reporting a crash 🙂 > The actual crash is not my concern. Should have probably indicated that in the first email 🙂 > There are several different ways that you can crash ansible on skipped > roles. Another way to do it is via > >     with\_sequence: start=1 end={{ numFoo }} > > where numFoo is 0. That obviously should be an error when the task is > run. What is surprising that ansible still crashes with "can't count > backwards" even if you tell it to skip the role containing the task: Conditionals are applied per loop step, not before the loop is evaluated.