You can read the preview of Contexts documentation here: https://circleci.com/docs/2.0/contexts/
Env vars are a great start.
I’d also love to see the ability to share some common build setup steps across repos. Every one of our projects that build in circle check out a repo with some shared setup scripts and runs a handful of steps to prep the environment. It would be awesome to figure out what it looks like to share that and make management of that a lot cleaner.
Totally agree - there are a couple things in the works related to config sharing across repos, some of which will be totally independent of Contexts. That said, we’ve talked about the concept of a “Context Job” that would execute before or after the job requesting the Context. That scenario would be good for central administration, guaranteeing the running of certain things (eg: security scan, special notifications, etc.) beyond the direct reach of the person running the job, but it wouldn’t be great for the scenario of sharing common bundles of config across many projects, necessarily. For straight code-sharing we’ll likely address that in coming enhancements to Workflows.
We’d like to configure webhooks across all of our builds.
Thread started here: Organization-wide webhooks
Thanks for getting this out.
All I really wanted was to have an environment variable which was a secret from forked PRs - it doesn’t seem like I got that here, or at least I did this:
- Created org-global on the web ui and added an environment variable to it
- Created a PR from an inside-org user (worked correctly, accessed that env var)
- Created a PR from an outside-the-org user, but in that PR the outside-the-org test (created by outside-the-org user) still was able to access the (private) env var.
Did I not understand at all what the org-global was going to do for me?
Very neat! Adding the ability to have subsets of project access various context resources would be useful, so for example an open source and private project within the same GitHub organization might have different values available to them.
Of course AWS Credentials would be awesome
Contexts would be a zillion times better if we could add these values via the API like we did before CircleCI 2.0. We have several environment variables we add programmatically right now via the API, but we would have to add these all manually via the website, which is a PITA.
My suggestion to CircleCI is to not add any new features that cannot be accessed via API calls.
Default chat notifications settings would also be great!
We have the same Slack channel for all our repos (failure/fixed builds)
Ability to copy env variables from a project in the repo (as you can do from one project to another) would be nifty. Just a one-time transition thing, though, so I imagine not a high priority.
is this supposed to work even without using workflows? I might be doing something wrong, but I can’t get this to work. Here is my circle file:
version: 2 jobs: build: environment: FOO: bar docker: - image: xxx working_directory: ~/tmp steps: - checkout - setup_remote_docker: reusable: true - run: name: Build and test context: org-global command: echo $MY_CONTEXT_VAR
MY_CONTEXT_VAR is not populated from the
org-global context as I’d expect. Am I missing something?
Contexts work only in Workflows, so you’d have to run the job from a Workflow.
Oh snap. Do you think it will available without workflows as well in the future? Seems like a job related concept so it doesn’t look strictly tied to workflows. Thanks!
It would be great to be able to apply a context to a “workflow” as well as a specific job. My use-case is that I have some org-global ENV variables i’d like applied to all jobs in a workflow and presently I have to specify the same “context” key on each job in my workflow which is many many jobs.
Thanks, I am really loving this feature though.
Any news for using it outside workflows? I’d like to know if this is on the roadmap or not. If I have something that doesn’t necessarily need workflows, should I make it a 1-step workflow just to use this feature?
That’s your best bet for now. We are not currently planning to support contexts on jobs outside of workflows to avoid confusion on which context is controlling a given execution of a job.
It would be good to make it clear when contexts are shared with child projects, particularly around pull requests. We have a mix of public and private projects in our organisation. We’d like to use contexts for common access keys that all our private projects need, but don’t want anyone to be able to open a PR against a public project to get hold of the keys.
I assume this is the default behaviour, but it’s not crystal clear.
Also, this seems like an odd limitation which would trip us up:
To rerun a job and use the context, it must be rerun from the Workflows page of the CircleCI application. Jobs invoked using the Rebuild button on the Builds page will not use the context defined in the workflow.
Jobs invoked using the Rebuild button on the Builds page will not use the context defined in the workflow.
not sure how that would be confusing, there is only one entry for definining a context in a job. so there wouldn’t be any ambiguity, can you give me an example if I am wrong?
“Confusion” was a bit strong, perhaps - the issue is that you’d need to have an order of resolution if you had a job with a context that was then called from a workflow with a different context. While formally you could disambiguate this to those who take the time to understand all the implications, it makes it easy for the person invoking the job with a context to end up with unexpected collisions of two contexts at two different layers (one in the workflow invocation(s) of the job, the other in the job itself) of their configuration. We may revisit this once there’s the ability to have multiple contexts available, at which point we’ll be making decisions on how one layers multiple contexts for a single job invocation. How contexts interact with each other is a more complex problem than it may seem, especially if and when contexts have more than just environment variables in them and/or have security rules to control access to contexts.