Ansible: Tags are a code smell

Your own code

Let’s look at an example. In this very simple playbook, we have four tasks: one with no tags, one with a non-special tag, one with the never special tag, and one with the always special tag:

- name: demo another always-tagged task
msg: I am another always-tagged task
- always
- another-always

Other peoples’ roles

Suppose you import someone else’s Ansible role through Galaxy or by other means, like this one. In my base playbook (we’ll just use the example, above) I never accounted for the other role author’s ‘security,’ ‘install,’ nor ‘configure’ tags when faithfully importing his (or her) role. If I run my own Ansible playbook and specify any of the tags I’m using, then the other author’s tasks simply won’t run.

Tags are a smell

You can’t use tags to *include* tasks without potentially skipping other tasks, and using special tags like ‘never’ and ‘always’ just makes running playbooks worse. Ansible’s command-line tools provide way too many ways to include or skip tags, leading to a difficult-to-diagnose mess.

What to use instead of tags?

There are other ways to work around using tags:

  • Use when conditionals and consider passing extra variables for conditional evaluation during ansible-playbook invocations using the ‘-e’ flag.
  • Write separate playbooks and invoke those, instead of your main playbook, when doing something simple with Ansible like reloading a service. Note that you can include specific tasks when importing an Ansible using the tasks_from argument to an include_role task.
  • Other ideas? Feel free to hit me up!



Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store