CLI: don’t attempt to update stack if template didn’t change #6216
Assignees
Labels
effort/small
Small work item – less than a day of effort
feature-request
A feature should be added or improved.
in-progress
This issue is being actively worked on.
package/tools
Related to AWS CDK Tools or CLI
Comments
eladb
added
feature-request
SomayaB
added
package/tools
|
@shivlaks I am picking this up |
eladb
pushed a commit
that referenced
this issue
Feb 18, 2020
Bail-out before executing and creating change sets when the currently deployed template is identical to the one we are about to deploy. This resolves #6046, where a stack that contains nested stack(s) will always try to update since CloudFormation assumes the nested template might have changed. In the CDK, since nested template URLs are immutable, we can trust that the URL will be changed, and therefore invalidate the *parent* template. This also fixes the bug described in #2553, where a stack that includes a `Transform` always fail to deploy with `No updates are to be performed` when there are no changes to it. The switch `--force` can be used to override this behavior. Added unit test and performed a few manual tests to verify both bugs are resolved. Resolves #6216
mergify bot
added a commit
that referenced
this issue
Feb 19, 2020
* feat(cli): skip deployment if template did not change Bail-out before executing and creating change sets when the currently deployed template is identical to the one we are about to deploy. This resolves #6046, where a stack that contains nested stack(s) will always try to update since CloudFormation assumes the nested template might have changed. In the CDK, since nested template URLs are immutable, we can trust that the URL will be changed, and therefore invalidate the *parent* template. This also fixes the bug described in #2553, where a stack that includes a `Transform` always fail to deploy with `No updates are to be performed` when there are no changes to it. The switch `--force` can be used to override this behavior. Added unit test and performed a few manual tests to verify both bugs are resolved. Resolves #6216 * Add alias -f for —force * Add integration test Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
|
Is there any reason the output regarding how to override (using the --force flag) is printed only at debug? I just spent quite a while trying to figure out some stacks weren't deploying (they used SSM parameters, so the template doesn't change, but if the parameter values change the stack needs to be updated), and this was the cause. It would have been much easier to debug what was going on if there was an output along with "no changes" stating why cdk thought there were no changes. |
|
This problems seems to be reintroduced with the DefaultStackSynthesizer. Created a new issue for it: #16959 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should add “short circuit” feature to the CLI which will skip change set creation and execution if the currently deployed template is identical to the one we are we’re requested to deploy.
Use Case
This will improve the user experience and will address two issues :
[aws-eks] Nested stacks always cause an update #6046: where nested stacks cause an update even if they haven’t changed. CloudFormation currently attempts to update nested stacks even if their template haven’t changed. This is because theoretically CFN can’t tell if the template had changed or not, but CDK nested stack templates are immutable and therefore if the URL didn’t change, we know for sure that an update is not needed.
"FAILED, No updates are to be performed" when adding a "Transform" to a stack #2553: creating a change set with no updates fails.
Proposed Solution
We should make this the default behavior but allow people to disable through something like
--forceOther
This is a 🚀 Feature Request
The text was updated successfully, but these errors were encountered: