feature request: append stack_tag inheritance

[zaro0508]

Currently stack_tags inheritance strategy is override which means that stack tags can be defined in a Sceptre StackGroup and then overridden in the a child StackGroup or Stack config. I would like to make a feature request to append stack_tags on a dependencies.

Example:
Assume Scepter project A, B and C with dependency C -> B

root StackConfig config/config.yaml

stack_tags:
  - country: US

config/prod/A.yaml

stack_tags:
  - city: anaheim    # stack A tags are 'city:anaheim', 'country:US'

config/prod/C.yaml

dependencies:
  - prod/B.yaml
stack_tags:
  - county: collin   # stack C tags are 'county:collin', 'country:US'

config/prod/B.yaml

stack_tags:
  - city: boston    # stack B tags are 'city:boston', 'county:collin', 'country:US'

[jfalkenstein]

Implementation on this should be fairly easy; Simply using the dict_merge strategy instead of the child_wins. The only concern here is that this could be considered a "breaking" change, as it would change the way existing sceptre configurations operate. But I love this idea and would like to see it happen.

[include]

I was thinking about - maybe adding this stack_tags: block at config.yaml level - it would apply automatically tags to all resources under a project/folder; without the need to add this block on each yaml cfn definition.

[jfalkenstein]

@include That already works in Sceptre. The challenge is when you want to mix tags in your deeper configs with higher level configs. Right now, the deeper configs override the higher level ones.

[okcleary]

Bumping this topic, I've very interested in this use-case as it would be very valuable for projects I work on (things like tags that are the same for a set of environments, but need to be extended down at each stack group).

I agree that changing the default strategy would be a big challenge, and would cause untold problems for existing configurations - not worth the trouble at all IMO.

To that end I feel that allowing the strategy to be defined by the config would be a better solution overall, not just for mitigating the problem of having to change the default behaviour.

The example here would be like

stack_tags_inheritance: dict_merge
stack_tags:
    tag_1: value_1
    tag_2: value_2

This could easily be applied to other merge-able config keys as well.

[okcleary]

I've put up a PR to add this feature for consideration.

I realised late that the original issue here indicates some inheritance of tags from dependants (config/prod/B.yaml), I don't think this fits the existing inheritance model nor does it seem to make sense to me so I haven't addressed it at this time.