@@ -7,7 +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.
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.
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 restricts use to protected branches. Protected branches 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.
