Skip to content
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

Closed
donkersgoed-postnl opened this issue Oct 13, 2021 · 4 comments · Fixed by #17099
Closed
Assignees
Labels
bug This issue is a bug. effort/small Small work item – less than a day of effort p1 package/tools Related to AWS CDK Tools or CLI

Comments

@donkersgoed-postnl
Copy link

donkersgoed-postnl commented Oct 13, 2021

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:

luc-IntegrationTestDev: checking if we can skip deploy
luc-IntegrationTestDev: skipping deployment (use --force to override)

 ✅  IntegrationTestCdkStack (luc-IntegrationTestDev) (no changes)

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.

@donkersgoed-postnl donkersgoed-postnl added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Oct 13, 2021
@github-actions github-actions bot added the package/tools Related to AWS CDK Tools or CLI label Oct 13, 2021
@rix0rrr
Copy link
Contributor

rix0rrr commented Oct 20, 2021

Interesting. Can you run cdk deploy -v and note the reason?

In case it is template has changed, can you then try:

$ aws cloudformation get-template --stack-name YOURSTACK > cfntemplate.json
$ diff cfntemplate.json cdk.out/YOURSTACK.template.json

And tell me what the differences are?

@rix0rrr rix0rrr added the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label Oct 20, 2021
@donkersgoed-postnl
Copy link
Author

A bit of background: these are two stacks that are being deployed together with cdk deploy --all --require-approval never -v. The deployment runs in GitHub Actions, so the container it runs in is replaced with every deploy.

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:

      - name: CDK Synth
        run: |
          cdk synth -q
      - name: Run EBE diff
        continue-on-error: true
        run: |
          aws cloudformation get-template --stack-name github-EventBrokerEcommerceDev --query 'TemplateBody' | jq -r > cfntemplate.json
          cat cdk.out/EbeBackendCdkStack.template.json | jq -r > local_template.json       
          diff cfntemplate.json local_template.json
      - name: Run IntegrationTest diff
        continue-on-error: true
        run: |
          aws cloudformation get-template --stack-name github-IntegrationTestDev --query 'TemplateBody' | jq -r > cfntemplate.json
          cat cdk.out/IntegrationTestCdkStack.template.json | jq -r > local_template.json
          diff cfntemplate.json local_template.json
      # Perform the deployment
      - name: Deploy EBE and latest integration tests
        run: |
          cdk deploy --all --require-approval never -v

Both the diffs give no output and exit code 0 (so there is no diff). But in the next step, it starts to deploy:

github-EventBrokerEcommerceDev: checking if we can skip deploy
github-EventBrokerEcommerceDev: parameters have changed
github-EventBrokerEcommerceDev: deploying...

@github-actions github-actions bot removed the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label Oct 20, 2021
@rix0rrr
Copy link
Contributor

rix0rrr commented Oct 21, 2021

github-EventBrokerEcommerceDev: parameters have changed

Iiiiiiiiiiiii see. Thanks!

rix0rrr added a commit that referenced this issue Oct 21, 2021
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.
@ryparker ryparker added effort/small Small work item – less than a day of effort and removed needs-triage This issue or PR still needs to be triaged. labels Oct 21, 2021
@mergify mergify bot closed this as completed in #17099 Oct 22, 2021
mergify bot pushed a commit that referenced this issue Oct 22, 2021
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*
@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

TikiTDO pushed a commit to TikiTDO/aws-cdk that referenced this issue Feb 21, 2022
)

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*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. effort/small Small work item – less than a day of effort p1 package/tools Related to AWS CDK Tools or CLI
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants