# how to always run code, regardless of tag

**URL:** <https://forum.ansible.com/t/how-to-always-run-code-regardless-of-tag/15225>\
**Category:** Ansible Project\
**Created:** [May 13, 2014, 7:49pm UTC](https://forum.ansible.com/t/how-to-always-run-code-regardless-of-tag/15225 "2014-05-13T19:49:27Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![chris\_snyder](https://avatars.discourse-cdn.com/v4/letter/c/7c8e57/32.png) [@chris\_snyder](https://forum.ansible.com/u/chris_snyder)\
**Post date:** [May 13, 2014, 7:49pm UTC](https://forum.ansible.com/t/how-to-always-run-code-regardless-of-tag/15225/1 "2014-05-13T19:49:27Z")

</div>

How do you always have a set of tasks run regardless of the tag being passed in on the command line?

I’m getting to the point where I have a ‘core’ playbook that must be run before any other playbook I have. This does specific things such as set specific facts based upon my local environments or OS distro that are to be used by all my later roles. However, when I use ‘—tags do\_this’ or ‘—tags do\_that’ tasks/roles executed in my core playbook are ignored because they aren’t tagged with ‘do\_this’ or ‘do\_that.’

It doesn’t seem reasonable (or scalable) to me to modify my core playbook and add every possible tag I can ever use, nor does it seem reasonable to force my fellow admins to always run Ansible with ‘—tags core,do\_this’ or ‘—tags core, do\_that’ when they only want a particular tag to be executed.

It really feels to me that Ansible is missing some way to say ‘this task/role/whatever REQUIRES this other code to be run as well’.

It seems I’m not alone in this – there’s some calls for similar functionality here:

- [https://github.com/ansible/ansible/issues/3157](https://github.com/ansible/ansible/issues/3157)

- [https://github.com/ansible/ansible/pull/7039](https://github.com/ansible/ansible/pull/7039)

So what should I be doing here?

Thx

Chris.

---

<div class="post-metadata">

**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 13, 2014, 7:53pm UTC](https://forum.ansible.com/t/how-to-always-run-code-regardless-of-tag/15225/2 "2014-05-13T19:53:39Z")

</div>

You should be tagging such tasks with something like ‘core’ like you say above, for now.

We would entertain an ‘all’ tag if well implemented, which I believe we’ve also said before.

“So what should I be doing here?”

Submitting a pull request? 🙂

---

<div class="post-metadata">

**Author:** ![Peter\_Gehres](https://avatars.discourse-cdn.com/v4/letter/p/f17d59/32.png) [@Peter\_Gehres](https://forum.ansible.com/u/Peter_Gehres)\
**Post date:** [May 13, 2014, 8:35pm UTC](https://forum.ansible.com/t/how-to-always-run-code-regardless-of-tag/15225/3 "2014-05-13T20:35:05Z")

</div>

I believe there is a pull request for an “all” tag at [https://github.com/ansible/ansible/pull/7039](https://github.com/ansible/ansible/pull/7039)

---

<div class="post-metadata">

**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 13, 2014, 8:50pm UTC](https://forum.ansible.com/t/how-to-always-run-code-regardless-of-tag/15225/4 "2014-05-13T20:50:54Z")

</div>

Good deal.

This is marked a “P3” ticket, so it’s in queue once we get the P2’s smited down properly… not too far away, hopefully!

---

<div class="post-metadata">

**Author:** ![Jaime\_Gago](https://avatars.discourse-cdn.com/v4/letter/j/71c47a/32.png) [@Jaime\_Gago](https://forum.ansible.com/u/Jaime_Gago)\
**Post date:** [July 28, 2014, 11:33pm UTC](https://forum.ansible.com/t/how-to-always-run-code-regardless-of-tag/15225/5 "2014-07-28T23:33:19Z")

</div>

IMHO This is somewhat related to the “always\_run” option which at this point in time is _only_ meant to override the “dry run” mode (–check) and execute the task no matter what. Unfortunately that doesn’t seem to work with --tags (i.e. a task marked with “always\_run” won’t be executed if the playbook is ran with a tag the task doesn’t have). Since it seems the direction is not to extend the “always\_run” option to also work with tags but instead modify core Ansible to be able to use a conventional “always run” tag then I’d vote for the “always\_run” option to be renamed.

Personally I would have preferred to keep it as an option to a task instead of a dedicated tag, first we already have an “always\_run” option and its name says it all in terms of what one would expect it to do to a task.  
Second with a conventional tag we will for the first time (unless I missed something) have to be _careful_ with how we pick our tags and that seems like a slippery slope. Imagine the newbie that didn’t read the specific 2 lines that says “if you use tag then that task will always be run no matter what”, nothing will let him know when he picks that tag that it’s doing something internally (i.e. always running the tasks), granted we could had something to the output e.g. “This task tagged to always run”, still though it leaves room for human error.  
My point being with an “always\_run” _option_ I have to explicitly call it as part of my playbook logic, tags as far I was concerned were always metadata to be leveraged during a playbook run; adding a “special” tag feature, however simple, breaks that rule and IMHO moves tags in the wrong direction.

My $.02 meh.

J.

---

<div class="post-metadata">

**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:** [July 29, 2014, 12:27am UTC](https://forum.ansible.com/t/how-to-always-run-code-regardless-of-tag/15225/6 "2014-07-29T00:27:48Z")

</div>

That’s a REALLY REALLY good proposal, though I’m worried a bit that changing the purposes of the flag might break an existing use case of check mode with tags.

Hindsight is definitely 20/20 though, and “always\_run” should have probably had the word “check\_mode” in there somewhere to make it clear at least.

Something like a “select\_tags” or “use\_tags” is probably what we’ll have to do.
