fix(cli): --no-previous-parameters incorrectly skips updates
#11288
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The CLI skips performing a CloudFormation deployment when it determines that the deployment will be a no-op (the CLI does this itself instead of deferring to CloudFormation because CloudFormation cannot accurately determine whether a changeset is going to be a no-op if Nested Stacks are involved, and we are looking to improve performance here). One of the aspects the CLI considers (after checking whether the templates are the same) is whether any Parameter values have changed. When `--no-previous-parameters` was passed, the code incorrectly completely ignored the existing Parameter values, which effectively led to it assuming that the "current values" on the stack were the same as the "default values" of the parameters. That meant that if a stack that was previously deployed with specific Parameter values, but then wanted to revert them to the defaults, this analysis would conclude that since the parameter values were equal to the defaults, there was "no change". In hindsight, this is obviously incorrect. The previous values should have been ignored for the purposes of determining the final paramater values and the CloudFormation API call parameters, but *not* for determining whether there is a change in parameter values between the current state of the stack and the new state of the stack.
|
|
njlynch
reviewed
Nov 4, 2020
| /** | ||
| * The values that change between the current and a new deployment | ||
| */ | ||
| export class ParameterChanges { |
There was a problem hiding this comment.
I don't see this being referenced anywhere. Vestigial remains?
njlynch
approved these changes
Nov 4, 2020
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The CLI skips performing a CloudFormation deployment when it determines
that the deployment will be a no-op (the CLI does this itself instead of
deferring to CloudFormation because CloudFormation cannot accurately
determine whether a changeset is going to be a no-op if Nested Stacks
are involved, and we are looking to improve performance here).
One of the aspects the CLI considers (after checking whether the
templates are the same) is whether any Parameter values have changed.
When
--no-previous-parameterswas passed, the code incorrectlycompletely ignored the existing Parameter values, which effectively
led to it assuming that the "current values" on the stack were the
same as the "default values" of the parameters.
That meant that if a stack that was previously deployed with specific
Parameter values, but then wanted to revert them to the defaults,
this analysis would conclude that since the parameter values were
equal to the defaults, there was "no change".
In hindsight, this is obviously incorrect. The previous values should
have been ignored for the purposes of determining the final
paramater values and the CloudFormation API call parameters, but not
for determining whether there is a change in parameter values between
the current state of the stack and the new state of the stack.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license