-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
inherit tags for canned_actions #599
base: main
Are you sure you want to change the base?
Conversation
@CroneKorkN do you agree? |
I actually have a usecase, where i need to tag each action independently: there are tags representing stages of app deployent, like
Maybe this could be resolved via an explicit |
I don't see a conflict between this PR and @CroneKorkN 's suggestion. Inheriting tags could still be the default behaviour that could be made overwriteable in a future commit/PR |
The problem is that this isn't backwards-compatible. Right now we actually have bundles that depend on a tag which is assigned to a service and world break if that dependency were to suddenly include the restart action as well. Nevertheless, I still agree that the behavior implemented in this PR is probably the right way to go, so I'm tagging it for 5.0. |
Thanks for the reply. I guess I will use a patched |
4435023
to
1849ef7
Compare
1849ef7
to
79031f2
Compare
Thanks to canned action, it is very easy to create dependency errors with code like this: ``` svc_systemd = { 'test.service': { 'tags': {'a'}, 'needed_by': {'!tag:a'}, }, } ``` Therefore canned actions should inherit the tags of their parent actions to avoid confisions by using the `!tag:foobar` selector.
Thanks to canned action, it is very easy to create dependency errors
with code like this:
Therefore canned actions should inherit the tags of their parent
actions to avoid confisions by using the
!tag:foobar
selector.