Context Restriction with Security Groups - Feedback #4875
Description
Location
https://circleci.com/docs/2.0/contexts/#approving-jobs-that-use-restricted-contexts
Explanation
Feedback 1:
In the below section of the online documentation, it refers to:
"Security groups are defined by GitHub teams."
It felt like this would have been more straightforward had the wording been something along the lines of 'Security groups are your organization's GitHub teams.' At the time that we were implementing this feature, it sounded like Security Groups were something that needed to be defined by the teams themselves (thus not already set up).
We found out that this was in fact just the list, but from someone that is not an admin it's unclear if further steps need to be taken prior to bringing in someone with Admin access.
Feedback 2:
This below section of the documentation seems to give the indication that someone who isn't part of this security group would still be able to approve the workflow, but that it would fail. In our testing, we found that someone outside of this security group wasn't able to approve the workflow. This seems to indicate that the documentation needs some updates.
"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."