-
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
Parameters default not being honored on update deploy #7576
Comments
This comment is how we were setting parameters #169 (comment) It seems like now the new context value isn't honored while in the past it was. More context is discussed here #1237 (comment) We implemented our stacks such that certain core.CfnParameters were injected defaults via context. Context items would be stuff like S3ObjectVersion or a CodeBuildId. We didn't notice it at first because our pipelines inject new parameters but a developer pushed a local stack build and we noticed the parameters didn't change but stayed what they were before even as the stacks parameter defaults change. So much for repeatability! |
It may have been how the assets are pipelined. Here is the old logic https://github.com/aws/aws-cdk/blame/7fcbc48adec5b4e883aafdd29a388c21077a3432/packages/aws-cdk/lib/api/deploy-stack.ts#L55 vs the new logic https://github.com/aws/aws-cdk/blame/986e2814e072f0334d8470a2d60ea73dcceadfe4/packages/aws-cdk/lib/api/deploy-stack.ts#L121-L131 The other smell is the re-use assets feature 1767b61 that seemed to change how parameters are resolved. |
For the time being we are doing stuff like:
It would be nice if I had a choice to manipulate the parameters in my app node but for now I basically I have to double down on some CLI arguments |
I don't really expect anything else to address this so I'll just let the thread be a tombstone. |
❓ General Issue
Recently the way CFN parameters are resolved has changed some expected behavior. Previously, because parameters didn't exist in cdk as an input it was recommended to add App context and then you could read the variable. We used this convention to set CfnParameter defaults which would change due to the context.
Now it appears that the previous stack parameters are being honored on an update and this is a change from before where the stack would deploy with the default values of the template as the actual parameter values of the deployment. Now the existing stacks parameters are being used.
Is there a way to disable this change that now uses existing stack parameters when an update is deployed?
Second, is there a suggested migrating path out of the "set the context and then set a parameter default value" solution? Are we able to set the parameters via the App context or Stack context when creating the object?
The Question
Environment
Other information
The text was updated successfully, but these errors were encountered: