Open madeline-k opened 3 years ago
The solution to this will probably involve some feature flag. I don't see how else it could work. I'm thinking:
{
"context": {
"@aws-cdk/core.taggableResources": "1.115.0"
}
}
Which will only apply tags to resources that were considered taggable in 1.115.0, or something like that.
That might actually be hard, the CloudFormation spec version might be easier, but further removed from users:
{
"context": {
"@aws-cdk/core.taggableResources": "3.38.0"
}
}
Uhh, what now?
Another alternative is to deprecate tree-based tagging and replace it with something more explicit.
Just ran into this issue. Thank you very much for providing a workaround, worked like a charm!
Would tagging via the CloudFormation Stack avoid problems like this? For CodePipeline CloudFormation Actions, would have to generate a separate file for stack configuration (Scroll down to TemplateConfiguration
here).
If a CDK user has added Tags to a construct, those tags will be added to all cloudformation resources within that construct's scope. If the Tags property was added to a resource via a cloudformation spec update, then when the CDK user updates their CDK version, a new Tags property will be added to that resource. This might not be what the user intended, and can cause deployment failures in some cases.
Reproduction Steps
Repro steps for one incarnation of this issue.
Deploy below sample with CDK version 1.113.0 or below.
Upgrade to CDK version 1.114.0 or greater.
What did you expect to happen?
Deployment succeeds after upgrade.
What actually happened?
Deployment failed with error "Update to resource type AWS::CodeDeploy::Application is not supported" after upgrade, because the "Name" tag was added to the CodeDeploy::Application resource inside the
LambdaDeploymentGroup
construct.Workaround
Explicitly remove tags from being added to specific resource types within your constructs.
This is :bug: Bug Report