Pass --tags and --skip-tags within a playbook

[jrobison-sb]

Proposal:

Author: John Robison <@jrobison-sb>

Date: 2021-10-06

• Status: New
• Proposal type: core design, I think
• Targeted release: <future release #, ex. 2.2>
• Associated PR: <link to GH PR in ansible/proposals if PR was submitted>
• Estimated time to implement: <X days, weeks, etc.>

Motivation

Motivation is to be able to get the same effect as --tags and --skip-tags, but from within a playbook in YAML instead of passing those arguments on the CLI.

Problems

I'd like to be able to use third party roles provided by the community and found on Galaxy and be able to pass --tags or --skip-tags to those roles and to be able to so within a playbook, such as with include_role.

For example, consider a third party role which implements CIS controls like this one: https://github.com/alivx/CIS-Ubuntu-20.04-Ansible. Currently --tags and --skip-tags can only be provided on the command line, so I might need to run a somewhat unwieldy command like this:

ansible-playbook \
--tags level_1_server \
--skip-tags 1.1.1.1 \
--skip-tags 1.1.1.2 \
...
/path/to/play.yml 

Solution proposal

It would be nicer if I could get the same effect as the above, but within a playbook and written as YAML, probably as part of include_role or similar.

- name: Run CIS controls from third party role
  include_role:
    name: alivx.cis_ubuntu_20_04_ansible
    # desired new functionality here:
    use_tags:
      - level_1_server
    skip_tags:
      - 1.1.1.1 # yaml supports comments so we can document exactly why this is being skipped, which we can't do effectively at the CLI level
      - 1.1.1.2 
      - "{{ '1.1.1.3' if ansible_distribution_major_version == 18 }}" # conditionally using/skipping tags is easy in a playbook and way harder at the CLI level

From a bit of googling I've seen that the above behavior is often what users expect the tags attribute of using a role does, like this:

---
- hosts: localhost
  roles:
    - common
    - role: alivx.cis_ubuntu_20_04_ansible
      tags: level_1_server # people mistakenly think this is going to do the same thing as what `--tags level_1_server` does 

Documentation

If the above proposal was implemented as part of include_role or whatever, it should be documented.

[bcoca]

We have had this request before and it has been rejected as it is a sign that roles are being constructed too big or complex.

if you HAVE to have such big/complex roles we encourage using tasks_from as a way to selectively execute sublists of tasks and structure the roles in such a way to make this possible.

[bcoca]

closing as per above, feel free to bring up in IRC meeting if you want to reopen the topic, but unless new arguments are brought up I don't see the outcome changing.