-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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: Add context validate/refresh commands #25828
Comments
Thank you for your feature request. Can you share more details about how the context values are invalid in your use case? If your CI fetches the values from SSM, I assume the it should always run
|
This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
Our CI system is not fetching SSM parameters and passing them as |
Describe the feature
The UX for managing cdk context is clunky and difficult to teach to new users (do you delete cdk.context.json?, manually edit the file? did you remove the key pertaining to the prod account or the dev account??). In addition, having all the values for SSM parameters persisted into a text file that is committed to source control somewhat removes the benefit of using SSM to drive parameters instead of using some local config files instead.
Use Case
We are finding the UX around keeping context values up to date to be frustrating. In our CI system, CDK deploy will use the out of date values (primarily for SSM parameters in our case) and either succeed with out of date values, or fail with an error that some value is invalid (e.g. ecs cluster ID is invalid) because the value from context is used rather than the fresh value stored in SSM. This type of error is not always obviously attributed to stale context by inexperienced devs causing time consuming trouble shooting.
Once the issue is identified, fixing the stale context would involve one of the following, all not ideal
cdk context --reset <number>
any number of times and re-synth2 of these options are inconvenient and the other could wipe context from other accounts/regions that is still accurate and should be kept.
Proposed Solution
Add 2 subcommands to the CDK context command:
cdk context validate
This command would use the same mechanism as originally populated the context to fetch fresh values for all keys and return with a non-zero exit status and useful log output if they are different from the cached values.
It should default to validating all keys for the current account/region if known, and take filter parameters to customize which keys to validate, i.e. to validate all keys associated with x account, or y region, or from z configprovider
The purpose of this command is to run on CI before a deploy or before a PR, or even a precommit hook, to ensure that stale context is not being used, and give the user a clear indication of which key is stale.
cdk context refresh
This command would use the same mechanisms for fetching context, to fetch fresh values for all keys and cache them in the cdk.context.json file. It would have the same filtering options and default behaviour as above to refresh keys relating to a specific provider, account or region or combination of the 3.
The purpose of this command would be for devs to run it during development in order to ensure the context being committed is fresh. Especially if your CI failed at
cdk context validate
on a PR, you would runcdk context refresh
and commit the fresh values to resolve the issue.Other Information
No response
Acknowledgements
CDK version used
2.80
Environment details (OS name and version, etc.)
MacOS 13.2.1 and NixOS 23.05
The text was updated successfully, but these errors were encountered: