cli: ability to pass context values through file

[virajkanwade]

Describe the feature

Context variables allow passing parameters to the cdk command. But since they need to be specified individually, reruns become a challenge. Keep track of what values have been used previously and pass them again. If there are multiple environments it become even more challenging and tedious.

Use Case

Reruns require me to remember and pass the same variables everytime. Also specifying each variable everytime is tedious.

Proposed Solution

The ability to store these values in a json file and passing it to the cli would be great feature for reusability and maintenance.

cdk deploy --context-file cdk.dev.json or cdk deploy --context-file cdk.stage.json -c "vpcEnv=qa"

Other Information

No response

Acknowledgements

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

CDK version used

2.62.2

Environment details (OS name and version, etc.)

MacOS Ventura

[virajkanwade]

There have been similar tickets reported earlier but they are now closed. https://github.com/aws/aws-cdk/issues/14948 and https://github.com/aws/aws-cdk/issues/2371

[virajkanwade]

I have submitted a PR https://github.com/aws/aws-cdk/pull/23912 implementing the feature, but since I have never worked on nodejs, need someone to address the tests.

[peterwoodworth]

You can use both cdk.json and cdk.context.json to pass in and reference as context values - have you tried these methods out?

[virajkanwade]

@peterwoodworth the objective here is maintaining and passing environment specific cdk.context.json. Separate files like cdk.context.dev.json, cdk.context.stage.json, cdk.context.prod.json.

[peterwoodworth]

I'm not sure how having multiple files here would be more helpful for organizing context. Context can contain objects, so you can specify context like so:

  "context": {
    "prod": {
      "context": "aws"
    },
    "dev": {
      "context": "cdk"
    }
  }

and reference it like so:

    const prod = this.node.tryGetContext('prod');
    console.log(prod.context);

    const dev = this.node.tryGetContext('dev');
    console.log(dev.context);

This can be generalized such that all you need to change is what's passed in to tryGetContext, and the context for your different environments can follow the same structure and be retrieved the same.

If you can provide more information about your use case to show why your proposal would be helpful (and why this approach wouldn't work), I'd love to hear it

[virajkanwade]

Hi @peterwoodworth Please see https://github.com/aws/aws-cdk/issues/2371 for history and comments https://github.com/aws/aws-cdk/issues/2371#issuecomment-616575230 https://github.com/aws/aws-cdk/issues/2371#issuecomment-700882628

[virajkanwade]

Putting everything in the same context file might not be preferable in every scenario. Say for eg prod. I would like to keep my prod configuration out of git. It could probably reside on S3, so only people who have access can download the file and refer the same. This is just an example and everything can have an alternative solution. Its just about what feels natural to work with.

[mward-LT]

I spent some time searching for this feature and found this Issue. I'll chime in here with a more "basic" use-case, which is: "just because I like it that way." Development workflow feels cleaner and easier to navigate when each environment has its own unique file, as opposed to one giant file where I'm scrolling around. Things get extra long when you start adding in multiple regions and each region has certain unique values.

Terraform has .tfvar files, Serverless Framework has built-in syntax for reading in any number of customized YAML option files, etc. --- it's not an entirely valueless feature. With those tools, I follow a format like $ENV_$REGION, so like dev_ap-northeast-1.tfvars, etc., then those two values are used at runtime (i.e. in a CI pipeline) to evaluate which file to load. The same concept can be used with the single context object in CDK, but again, it just makes for a better developer user experience being able to compartmentalize each into their own file.

[karmabadger]

yeah this is long due. it's just like being able to have .env.dev and .env.prod. it's not even just for the context, but just to have an isolated prod cdk.json that won't be touched.