@@ -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.
The group token will 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 this 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.
The group token is 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 this 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.
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.
