Tags assigned to first stack apply to un-related stacks

[sd0408]

Note: for support questions, please first reference our documentation, then use Stackoverflow. This repository's issues are intended for feature requests and bug reports.

• I'm submitting a ...

  • 🪲 bug report
  • 🚀 feature request
  • 📚 construct library gap
  • ☎️ security issue or vulnerability => Please see policy
  • ❓ support request => Please see note at the top of this template.

• What is the current behavior?
  If the current behavior is a 🪲bug🪲: Please provide the steps to reproduce

1. Create a stack setting some tags
2. Create another stack setting some different tags
3. cdk deploy MyStack

Then I notice that the tags on the second stack are the same as the tags on the first stack. Thus, the values of the tags on the second stack are being ignored.

class FooStack(core.Stack):

    def __init__(self, scope: core.Construct, id: str, tags, **kwargs) -> None:
        super().__init__(scope, id, tags=tags, **kwargs)

app = core.App()

initial_tags ={"foo": "bar"}
other_tags = {"foo2": "alsobar"}

FooStack(app, "foo", tags=initial_tags)
FooStack(app, "foo2", tags=other_tags)

app.synth()

I have noticed that if I instantiate the first stack with an empty tag set then the second stack does get it's tags as you would expect.

• What is the expected behavior (or behavior of feature suggested)?
  When I instantiate either a stack object or a child of a stack object the tags supplied to work for that stack instance and only for that stack instance.

• What is the motivation / use case for changing the behavior or adding this feature?
  Would like to be able to apply different sets of tags to different objects.

• Please tell us about your environment:

  • CDK CLI Version: 1.2.0
  • Module Version: 1.1.0
  • OS: OSX Mojave
  • Language: I've only used Python

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. associated pull-request, stackoverflow, gitter, etc)

[eladb]

See #3455

[sd0408]

Thanks... same issue. I promise I searched

[NGL321]

@sd0408 It actually really helps to have this in an issue as well as a PR so it comes up in other people's searches later! 😸

Thanks for making a post! This will close out when the PR merges.