I was switched to the new UI today and I noticed that while setting up new projects the “Import Environment Variables”. We use this feature when setting up new projects to share api keys that are required to talk to our backend.
1 Like
It looks like contexts fits my use case and is easier to use going forward. Thanks
Hello @nemosupremo! Contexts is an ideal option to consider as @DominikGM mentions.
Another option is to create environment variables via the v2 API. You can read more about this here: https://circleci.com/docs/api/v2/#create-an-environment-variable
It looks like contexts requires using the new CircleCI config however…?
Thanks for suggesting some alternatives.
Just wanted to provide some additional feedback about a use case which is not covered by switching to contexts.
Many of our projects use different contexts depending on the job. We then use project-level environment variables for common values that should be set for all jobs in a project regardless of which context they use.
In order to switch to contexts entirely, we would require the ability to specify multiple contexts per job. Since this is not supported, we use the import feature to copy these values from other projects.
1 Like
Is my understanding of Environment and Context wrong?
The way I understood it was that the Environment was for nonspecific environments that do not have secrets. And do not need special permissions to have access to them
Example:
- someLimitThatAppliesToEverything=“5”
And Context was meant for something specific. Like a secret that is used for different stages that I don’t want to commit in my source code like an access key
Example:
Prod
- ACCESS_KEY=“A”
Release - ACCESS_KEY=“B”
Test - ACCESS_KEY=“C”
etc
I mean if you could apply more than one Context to a job I think deprecating the Environment section is alright, but If I need to apply one generic config to my runtime and one specific config at the same time, then I definitely need it.