CCCHH/ansible-infra

Fork 1

Add role name as tag to all basic roles #85

Closed

lilly wants to merge 6 commits from add-basic-tags into main

lilly commented

2026-04-30 23:09:00 +02:00

Owner

Sometimes it is quite annoying when developing or debugging a specific part of the configuration to have to run the whole thing. To make things easier, the base set of roles that we use all over the place have been given a tag corresponding to their role name.

lilly self-assigned this

2026-04-30 23:09:01 +02:00

lilly requested review from june

2026-04-30 23:09:11 +02:00

lilly force-pushed add-basic-tags from 9aeedc3e78

/ Ansible Lint (push) Failing after 2m26s

Details

/ Ansible Lint (pull_request) Failing after 2m23s

Details

to 5787a9d792

/ Ansible Lint (push) Failing after 2m30s

Details

/ Ansible Lint (pull_request) Failing after 2m32s

Details

2026-04-30 23:19:53 +02:00

Compare

lilly force-pushed add-basic-tags from 5787a9d792

/ Ansible Lint (push) Failing after 2m30s

Details

/ Ansible Lint (pull_request) Failing after 2m32s

Details

to 1d54043b8e

/ Ansible Lint (push) Successful in 2m38s

Details

/ Ansible Lint (pull_request) Successful in 2m38s

Details

2026-05-01 00:33:47 +02:00

Compare

june requested changes

2026-05-01 22:29:45 +02:00

june left a comment

Any specific reason for adding the tags on a per-task level instead of where the roles get imported?
This seems like a lot of manual tagging, which could result in missing tags slipping through in the future and also doesn't provide tag inheritance, which results in somewhat unintuitive behavior for roles with dependencies.

Any specific reason for adding the tags on a per-task level instead of where the roles get imported? This seems like a lot of manual tagging, which could result in missing tags slipping through in the future and also doesn't provide tag inheritance, which results in somewhat unintuitive behavior for roles with dependencies.

lilly commented

2026-05-01 23:18:20 +02:00

Author

Owner

An alernative, less repetitive option would be to do

- tags: [ "rolename" ]
  block:
    - name: Some task

    - name: Some other task

Because the tag is a detail of the role itself and not a concern of where the role is called. If we would set it where the role is used, the same argument you take can be made for forgetting to set int on a different playbook where the role is used too. An alernative, less repetitive option would be to do ```yaml - tags: [ "rolename" ] block: - name: Some task - name: Some other task ```

june commented

2026-05-01 23:24:25 +02:00

Owner

@lilly wrote in #85 (comment):

Because the tag is a detail of the role itself and not a concern of where the role is called. If we would set it where the role is used, the same argument you take can be made for forgetting to set int on a different playbook where the role is used too.

An alernative, less repetitive option would be to do
- tags: [ "rolename" ]
  block:
    - name: Some task

    - name: Some other task

Ugh, guess Ansible really gives us no nice option here. Wrapping everything in a block is quite ugly as well, tagging the individual tasks misses dependencies and tagging at the playbook level does indeed result in the mentioned problem.
I guess we should ask ourselves what we are trying to achieve: If our goal is to enable us to only run parts of a complex role then tagging at the task level does indeed seem like the right option, however if our goal is being able to only run parts of a complex playbook, then tagging at the play(book) level does seem more reasonable.

@lilly wrote in https://git.hamburg.ccc.de/CCCHH/ansible-infra/pulls/85#issuecomment-4214: > Because the tag is a detail of the role itself and not a concern of where the role is called. If we would set it where the role is used, the same argument you take can be made for forgetting to set int on a different playbook where the role is used too. > > An alernative, less repetitive option would be to do > > ```yaml > - tags: [ "rolename" ] > block: > - name: Some task > > - name: Some other task > ``` Ugh, guess Ansible really gives us no nice option here. Wrapping everything in a block is quite ugly as well, tagging the individual tasks misses dependencies and tagging at the playbook level does indeed result in the mentioned problem. I guess we should ask ourselves what we are trying to achieve: If our goal is to enable us to only run parts of a complex role then tagging at the task level does indeed seem like the right option, however if our goal is being able to only run parts of a complex playbook, then tagging at the play(book) level does seem more reasonable.

lilly commented

2026-05-02 01:06:01 +02:00

Author

Owner

I would say that our goal is to run parts of a playbook. My main use-case is that I'm configuring a specific service on a VM in which case I don't want to run all the base_config and utility roles.

I would say that our goal is to run parts of a playbook. My main use-case is that I'm configuring a specific service on a VM in which case I don't want to run all the `base_config` and utility roles.

june commented

2026-05-02 01:13:42 +02:00

Owner

I would then just tag all the plays at the playbook level and keep tagging at the task level for use cases, where we want to enable running only part of a role.
I think this also makes it easier to achieve our goal for this PR as the relevant playbook just needs to be changed instead of multiple roles.

I would then just tag all the plays at the playbook level and keep tagging at the task level for use cases, where we want to enable running only part of a role. I think this also makes it easier to achieve our goal for this PR as the relevant playbook just needs to be changed instead of multiple roles.

june referenced this pull request

2026-05-18 18:16:33 +02:00

tag playbooks #93

lilly closed this pull request

2026-05-19 08:31:38 +02:00