From e81ed0e730cf1ca7ddba3276c66f385a1e0f3ba6 Mon Sep 17 00:00:00 2001 From: thomasr8 Date: Wed, 24 Feb 2021 15:10:25 -0600 Subject: [PATCH] Update contexts.md Minor changes to fix language in the contexts documentation. This fixes #4875 --- jekyll/_cci2/contexts.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/jekyll/_cci2/contexts.md b/jekyll/_cci2/contexts.md index 681bed216a..62e3303e16 100644 --- a/jekyll/_cci2/contexts.md +++ b/jekyll/_cci2/contexts.md @@ -27,7 +27,9 @@ Create and manage contexts on the Organization Settings page of the CircleCI app To use environment variables set on the Contexts page, the person running the workflow must be a member of the organization for which the context is set. -Context names must be unique for each GitHub or Bitbucket organization. **Note:** Contexts created with the initial default name of `org-global` will continue to work. +Context names must be unique for each GitHub or Bitbucket organization. + +**Note:** Contexts created with the initial default name of `org-global` will continue to work. ### Context naming for CircleCI server {:.no_toc} @@ -121,7 +123,7 @@ You can combine several contexts for a single job by just adding them to the con ## Restricting a context -CircleCI enables you to restrict secret environment variables at run time by adding security groups to contexts. Only organization administrators may add *security groups* to a new or existing context. Security groups are defined by GitHub teams. If you are using CircleCI Server with LDAP authentication, then LDAP groups also define security groups. After a security group is added to a context, only members of that security group who are also CircleCI users may access the context and use the associated environment variables. +CircleCI enables you to restrict secret environment variables at run time by adding security groups to contexts. Only organization administrators may add *security groups* to a new or existing context. Security groups are your organization's GitHub teams. If you are using CircleCI Server with LDAP authentication, then LDAP groups also define security groups. After a security group is added to a context, only members of that security group who are also CircleCI users may access the context and use the associated environment variables. Organization administrators have read/write access to all projects and have unrestricted access to all contexts. @@ -182,7 +184,7 @@ workflows: - test ``` -In this example, the jobs `test` and `deploy` are restricted, and will only run if the user who approves the `hold` job is a member of the security group assigned to the context `deploy-key-restricted-context`. When the workflow `build-test-deploy` runs, the `build` job will run, then the `hold` job, which presents a manual approval button in the CircleCI application. This approval job may be approved by _any_ member, but the jobs `test` and `deploy` will fail as `unauthorized` if the "approver" is not part of the restricted context security group. +In this example, the jobs `test` and `deploy` are restricted, and will only run if the user who approves the `hold` job is a member of the security group assigned to the context `deploy-key-restricted-context`. When the workflow `build-test-deploy` runs, the `build` job will run, then the `hold` job, which presents a manual approval button in the CircleCI application. This approval job may be approved by _any_ member of the security group, but the jobs `test` and `deploy` will fail as `unauthorized` if the "approver" is not part of the restricted context security group. ## Removing groups from contexts