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

Parameters default not being honored on update deploy #7576

Closed
joekiller opened this issue Apr 23, 2020 · 4 comments
Closed

Parameters default not being honored on update deploy #7576

joekiller opened this issue Apr 23, 2020 · 4 comments
Labels
needs-triage This issue or PR still needs to be triaged.

Comments

@joekiller
Copy link

❓ 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

  • CDK CLI Version:
  • Module Version:
  • OS:
  • Language:

Other information

@joekiller joekiller added the needs-triage This issue or PR still needs to be triaged. label Apr 23, 2020
@joekiller
Copy link
Author

joekiller commented Apr 23, 2020

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!

@joekiller
Copy link
Author

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.

@joekiller
Copy link
Author

For the time being we are doing stuff like:

--parameters "StackName:blah=blah"
-c "blah=blah"

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

@joekiller
Copy link
Author

I don't really expect anything else to address this so I'll just let the thread be a tombstone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-triage This issue or PR still needs to be triaged.
Projects
None yet
Development

No branches or pull requests

1 participant