(pipelines): versionReporting and --no-version-reporting not respected for support stacks
#18933
Labels
Comments
gshpychka
added
bug
gshpychka
changed the title
and --no-version-reporting` not respected for support stacksversionReporting and --no-version-reporting not respected for support stacks
NGL321
added
p2
and removed
needs-triage
|
@NGL321 Why is nobody assigned this? Shouldn't the inability to disable telemetry be P1? |
rix0rrr
added a commit
that referenced
this issue
Feb 17, 2022
When we moved analytics generation from the CLI to the framework, we kept a fallback in the CLI for backwards compatibility: if there were no analytics in the templates but analytics were requested, they would still be added in the CLI. This breaks in the case of CDK Pipelines self-mutate step, if analytics have been disabled: there are no analytics in the template, and the default setting for analytics is `true`, since there is no `cdk.json` to opt out, so they will always be added back in. A better solution to check whether the CLI needs to do the fallback is to go off of the cx schema version number: the CLI can know that it never needs to do anything for cloud assemblies generated starting at a certain version. Fixes #18933.
mergify bot
pushed a commit
that referenced
this issue
Feb 17, 2022
When we moved analytics generation from the CLI to the framework, we kept a fallback in the CLI for backwards compatibility: if there were no analytics in the templates but analytics were requested, they would still be added in the CLI. This breaks in the case of CDK Pipelines self-mutate step, if analytics have been disabled: there are no analytics in the template, and the default setting for analytics is `true`, since there is no `cdk.json` to opt out, so they will always be added back in. A better solution to check whether the CLI needs to do the fallback is to go off of the cx schema version number: the CLI can know that it never needs to do anything for cloud assemblies generated starting at a certain version. Fixes #18933. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
|
@gshpychka thank you for bringing this to our attention! |
TikiTDO
pushed a commit
to TikiTDO/aws-cdk
that referenced
this issue
Feb 21, 2022
When we moved analytics generation from the CLI to the framework, we kept a fallback in the CLI for backwards compatibility: if there were no analytics in the templates but analytics were requested, they would still be added in the CLI. This breaks in the case of CDK Pipelines self-mutate step, if analytics have been disabled: there are no analytics in the template, and the default setting for analytics is `true`, since there is no `cdk.json` to opt out, so they will always be added back in. A better solution to check whether the CLI needs to do the fallback is to go off of the cx schema version number: the CLI can know that it never needs to do anything for cloud assemblies generated starting at a certain version. Fixes aws#18933. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the problem?
The pipeline is adding
AWS::CDK::Metadataresource to the support stacks regardless of theversionReportingvalue and even if the synth command iscdk --no-version-reporting synth.Reproduction Steps
"versionReporting": falseincdk.jsoncdk --no-version-reporting synthin the Synth stepAWS::CDK::Metadataresource.What did you expect to happen?
No changes to the support stacks.
What actually happened?
The self-mutate action adds the
AWS::CDK::Metadatato the support stacks.If I do a
cdk deployfrom my local machine again, the resource will be deleted.CDK CLI Version
2.12.0
Framework Version
2.12.0
Node.js Version
17.3.0
OS
ArcLinux
Language
Python
Language Version
3.9.10
Other information
No response
The text was updated successfully, but these errors were encountered: