Can’t wait to see that.
+1 this request! I have 9 shared environment variables that I would like have in all projects across my organization. Copying and pasting this in every new project is a pain
Would love to have this feature.
+1! Been copying my NPM auth token to 20+ projects built on CircleCI…
Same here, I prefer an inherited-environment-variables-structure with a Tree model of projects.
Agree this would be useful. Even more useful is the ability to set vars for sub-branches, so that it’s possible to isolate environments – e.g. to use separate AWS accounts for test vs prod vs staging.
Here’s a link to a script I wrote to escape the tedium:
+1 to this!
In addition to Org-wide environment variables, org-wide setup commands would be useful.
We need to run a few commands to configure our external npm repository, being able to set that once, instead of having to duplicate the commands repeatedly in our circle.yml files would be helpful.
We could really use this!
I ended up creating a postman collection to run to build it up.
We are getting ready to have not to worry about it anymore after I finish the full integration into our one-click micro-service project setup.
Although it wouldn’t hurt.
This is a must have, I have around 20 repositories and all need some private npm modules. I neither want to set up 3 environment variables for logging into npm nor I want to create a scripts which does this in each step. Would be awesome!
A response from CircleCI staff about the status of this would be appreciated.
Thanks for the reminder! An inheritable variable is a great idea.
I generally only try to comment when I can say something like “Yes, that will be shipped soon”. Unfortunately not there yet, but I will say - this idea makes sense and our team is actively putting it into plans.
We’re working on some pretty big shifts to make the build engine more reliable and faster - as well as making the configuration more extensible and friendly to complex teams with trying to create workflows - and shifting towards a more flexible/fairer pricing model.
Circle 2.0 is the first step towards that (it covers the faster/more reliable build engine). If you haven’t signed up for the beta waitlist yet, please do! https://circleci.com/beta-access/
Please add this feature
Here’s the duplicate feature request for 2.0.
just scoped out a pretty quick solution to this. Would love to get feedback from folks - including OP @Josh_a_e (although it’s been awhile since you requested this )
In Project Settings, we give an option to “Import Variables”. Then you choose a project within your org (that has the env vars you want) and can bring over all/some of those variables in a one-time copy/paste.
Here’s a mock:
This is a “pull” model, supposing the variables exist on a different project you already set up and you want to grab them there from there.
We’ve considered a “push” model as well - but as of now, the discussion is that will be best from a hierarchical top-down UX. To unpack that further - we believe that users will want to set this at an Organization (or Install for our behind-the-firewall customers) level and allow control from there (i.e., an admin of the org picks the projects to push the variables into). We also believe there is real value for teams in allowing that to be a consistent sync (as opposed to a one-time copy/paste). This is likely what we’d consider next, especially if this feature is popular.
However, in the meantime, this seems like it would solve the use-case and be much better than the current state! Please let me know if I messed up understanding your use case and thanks for the FR!
edit: Realized that many folks don’t have “Notify me if there’s a response on this thread” on. Going to ping a couple to see if I can’t get some user feedback on the proposed feature. @DominikGM @jclinto1 @Bekt @steebchen @jeremy2 @AlexHayton @jbcpollak @robert @Maarten
another edit: We shipped this version!
that’s a great update. You made my colleague and me happy
We would prefer the “consistent sync” feature as most environment variables are common for each repository. Pushing would be quite the same as now setting the env via API. So, pulling from a “template repository” and synchronising changes in there would be neat.
- Only list the repositories which are actually built in CircleCI (in the dropdown list).
- Searching/filtering in the variable names could be helpful if you want to pick just some envs in a long list.
I have a lot of build that have the same set of environment variables. E.g.:
- CIRCLE_TOKEN - in all of my builds
- DOCKER_PASSWORD - in some of my builds
I’d like to be able to create a group of variable and then have the jobs choose the groups. Could even be yml based.
This needs to be available for more than just org admins. Repo admins at least, preferably any user w/ write access to the repo.
+1. Organization wide variables or groups of variables would be very helpful!