@@ -7,13 +7,7 @@ The `CI_API_TOKEN` CI Variable has the value set to the GROUP_API_TOKEN group to
The `CI_PUSH_KEY_VALUE` CI Variable has the value set to `GROUP_PUSH_TOKEN:<Value>` with `<Value>` being the actual value of the GROUP_PUSH_TOKEN. So, unlike the CI_API_TOKEN, the CI_PUSH_KEY_VALUE includes the name of Group Token.
The group tokens are currently configured to only work on protected branches. By default the main branch is not protected in each project, so each project must setup the branch protection in Settings. The group token requires Developer permissions on the main branch.
It's not exactly clear if branch protection is necessary since only authenticated users can push to main anyways, but I might be missing something subtle, like a guest user can fork the repo and inherit the workflow and then muck with it. So I configured the token with branch protection required just in case. If someone can convince me it's mute to do so and only causes hassle, then we can change this.
There is a group level Setting to set default branch protection rule configuration. However, turning it on and clicking save results in messages saying it worked, but on refresh, the setting doesn't stick. Oh well. First bug found I guess.
Note: the goal is to avoid exposing the secret token. If an authorized user wants to expose it they can. Please don't. The variable is marked as both `hidden` and `masked`. This means GitLab makes some effort to obscure the value. This isn't perfect though, so for example an authorized user can expose it by creating a job that prints the entire env. Please don't do this.
Note: It's important to avoid exposing the secret token value. If an authorized user wants to expose it they can. Please don't. The variable is marked as both `hidden` and `masked`. This means GitLab makes some effort to obscure the value. This isn't perfect though, so for example an authorized user can expose it by creating a job that prints the entire env. Please don't do this. We do not use the `protected` flag as that is overly onerous and unnecessary - it applies more fine-grained restrictions on top of the role based access controls and optionally allows blocking force-push.
# Steps
Another experimental feature, [Steps](https://docs.gitlab.com/ci/steps/) may make our pipelines easier to understand and more performant. Steps don't appear to be supported on our code.jlab.org install at the moment. A no step_runner found error results when attempting to use.
