-
Notifications
You must be signed in to change notification settings - Fork 4k
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
(CLI): The DefaultStackSynthesizer executes change sets for no-op nested stacks #16959
Comments
Interesting. Can you run In case it is
And tell me what the differences are? |
A bit of background: these are two stacks that are being deployed together with The first stack has nested stacks, the second doesn't. The second stack uses exported values from the first. The second stack detects no changes. The first stack is always redeployed, this is the GitHub Actions workflow:
Both the diffs give no output and exit code 0 (so there is no diff). But in the next step, it starts to deploy:
|
Iiiiiiiiiiiii see. Thanks! |
The `DefaultSynthesizer` always adds an SSM parameter with the bootstrap stack version, so that it can check that the bootstrap stack has a recent enough version. Unfortunately, the CDK CLI will refuse to short-circuit any deployment that uses SSM parameters, because it can't tell if the parameter has changed, and so it has to pessimize. Adding a magic marker to the description of the parameter will now exempt it from the check. Fixes #16959.
The `DefaultSynthesizer` always adds an SSM parameter with the bootstrap stack version, so that it can check that the bootstrap stack has a recent enough version. Unfortunately, the CDK CLI will refuse to short-circuit any deployment that uses SSM parameters, because it can't tell if the parameter has changed, and so it has to pessimize. Adding a magic marker to the description of the parameter will now exempt it from the check. Fixes #16959. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
) The `DefaultSynthesizer` always adds an SSM parameter with the bootstrap stack version, so that it can check that the bootstrap stack has a recent enough version. Unfortunately, the CDK CLI will refuse to short-circuit any deployment that uses SSM parameters, because it can't tell if the parameter has changed, and so it has to pessimize. Adding a magic marker to the description of the parameter will now exempt it from the check. Fixes aws#16959. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
What is the problem?
In an environment with nested stacks, two subsequent deploys without changes between them result in a full (slow) deployment. This has been solved for the LegacyStackSynthesizer (see #6346 and #6046), but the issue is present again with the DefaultStackSynthesizer.
Reproduction Steps
Using the DefaultStackSynthesizer create a stack with nested stacks and run a
cdk deploy
.What did you expect to happen?
No deployment and the following (verbose) output:
What actually happened?
A changeset is created and executed.
CDK CLI Version
1.122.0
Framework Version
No response
Node.js Version
v16.8.0
OS
MacOS 10.15.7 (19H1419)
Language
Python
Language Version
Python (3.8.12)
Other information
When I use the LegacyStackSynthesizer on the same code base, the results are as expected. When I switch to the DefaultStackSynthesizer, I get the results described above.
The text was updated successfully, but these errors were encountered: