(construct): Private context file & context precedence

[amkuchta]

Description

Reading through the Runtime Context documentation, a few things jump out at me:

1. There isn't any indication on which locations that the context can be set in take precedence over the other. Reading through the documentation, it appears that the order is --context > cdk.context.json > cdk.json, however, I have found that setting my context in the cdk.context.json file gets overwritten by values provided in cdk.json, and both are overridden by the --context flag. Some clarity on this would be awesome!
2. The documentation states that context files should be checked into source control - what if I would prefer to keep my context out of SCM? It would be nice to have either a separate file that tryGetContext looks for (e.g. private.cdk.context.json, for example), or the ability to pass a file in via a --context-file flag

Use Case

Let's say I am working with an open-source implementation of the CDK, such as the AWS Video on Demand implementation (which I am currently porting from CloudFormation to the CDK). In this instance, I may want to have my own runtime context variables that overwrite the defaults but do not belong in source control (overwriting the cdk.json file means that I need to stash my changes to pull updates from upstream, and even then I run the risk of discrepancies).

Proposed Solution

Provide either of the following:

1. A file that is expected to contain read-only context values (e.g. private.cdk.context.json) and will never be altered with cached values, or
2. The ability to specify an additional context file via a flag (e.g. --context-file)

Other

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

---

This is a 🚀 Feature Request

[rix0rrr]

Those are fair requests. I'd be interested to hear what kind of context values you'd want to be storing.

I think:

• The reusable unit that is checked into CloudFormation should probably be a construct, or construct library, and not an app with an entry point and context -- although I see we currently don't have facilities to make consuming and deploying that library easy.
• To work around current limitations, a wrapper script that either passes --context or modifies the json files on disk is probably your best bet.

[amkuchta]

@rix0rrr I'm glad you think it is reasonable! An example of some of the items I am storing as a context variable:

• An enableSns flag to opt into or out of SNS Notification creation
• A cloudFrontDomain that can be used to create a certificate and CloudFront distribution
• An S3 archive option (GLACIER, DEEP_ARCHIVE, or DISABLED)

Items like these should be able to easily be set once and forgotten about rather than having to remember to plug them into the cdk deploy command or set them in a bunch of pipeline variables and then make sure they are all called when the pipeline runs.

For a full example of how I am using context variables (I'm currently just overwriting the defaults in the cdk.json, then stashing that file before pushing / pulling other changes. Then, I retrieve the variables for use elsewhere in _context-variables.ts):

cdk.json
_context-variables.ts

[github-actions]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[amkuchta]

Well crud... Can I get this re-opened, @rix0rrr?