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:
So what should I be doing here?
Thx
Chris.
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? 
I believe there is a pull request for an “all” tag at https://github.com/ansible/ansible/pull/7039
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!
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.
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.