CLI: Add context validate/refresh commands

[frogamic]

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

• manually edit cdk.context.json to remove the offending value and then re-synth
• delete cdk.context.json and re-synth
• use cdk context --reset <number> any number of times and re-synth
  2 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 run cdk context refresh and commit the fresh values to resolve the issue.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.80

Environment details (OS name and version, etc.)

MacOS 13.2.1 and NixOS 23.05

[pahud]

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 cdk context --reset KEY before the cdk synth --context key=value to avoid using the cached value?

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.

[github-actions]

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.

[frogamic]

If your CI fetches the values from SSM, I assume the it should always run cdk context --reset KEY before the cdk synth --context key=value to avoid using the cached value?

Our CI system is not fetching SSM parameters and passing them as --context ... options, it is using CDK context system, i.e. let CDK get the value from cdk.context.json or look it up during synth. The problem is that as long as we check cdk.context.json into version control, as all advice suggests, these values can be stale. If our CI ran cdk context --clear before a build, that seems like it would ruin many of the benefits of checking the context.json into version control (i.e. repeatability/deterministic deploys)