You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 2384fe3
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: docs/site/docs-en/ci/gitlab-ci.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -45,6 +45,12 @@ release:
45
45
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
46
46
```
47
47
48
+
## Using `CI_JOB_TOKEN`
49
+
50
+
The examples above pass the job token as `GITLAB_TOKEN: $CI_JOB_TOKEN`. FerrFlow recognises it because its value equals `CI_JOB_TOKEN`, and authenticates the way GitLab expects for a job token: API calls carry a `JOB-TOKEN` header and git pushes as `gitlab-ci-token`. The same applies when the job token is passed as `FERRFLOW_TOKEN`. Any other token (project, group or personal access token) is sent as `PRIVATE-TOKEN` and pushes as `oauth2`.
51
+
52
+
What a job token may do is set per project under **Settings > CI/CD > Job token permissions**. Pushing the release commit and tags needs **Allow Git push requests to the repository**. When GitLab refuses one of the API calls FerrFlow makes with a job token, use a project access token with the `api` scope instead.
53
+
48
54
## Using a deploy token
49
55
50
56
If `CI_JOB_TOKEN` doesn't have permission to push tags, create a project deploy token with `write_repository` access and store it as a CI variable:
Copy file name to clipboardExpand all lines: docs/site/docs-fr/ci/gitlab-ci.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -45,6 +45,12 @@ release:
45
45
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
46
46
```
47
47
48
+
## Utiliser `CI_JOB_TOKEN`
49
+
50
+
Les exemples ci-dessus passent le token du job via `GITLAB_TOKEN: $CI_JOB_TOKEN`. FerrFlow le reconnaît parce que sa valeur est égale à `CI_JOB_TOKEN`, et s'authentifie comme GitLab l'attend pour un token de job : les appels d'API portent un en-tête `JOB-TOKEN` et git pousse en tant que `gitlab-ci-token`. C'est aussi le cas quand le token du job est passé dans `FERRFLOW_TOKEN`. Tout autre token (token d'accès de projet, de groupe ou personnel) est envoyé en `PRIVATE-TOKEN` et pousse en tant que `oauth2`.
51
+
52
+
Ce qu'un token de job a le droit de faire se règle par projet dans **Settings > CI/CD > Job token permissions**. Pousser le commit et les tags de release nécessite **Allow Git push requests to the repository**. Quand GitLab refuse un des appels d'API que FerrFlow fait avec un token de job, utilisez plutôt un token d'accès de projet avec le scope `api`.
53
+
48
54
## Utiliser un deploy token
49
55
50
56
Si `CI_JOB_TOKEN` n'a pas les permissions pour pousser des tags, créez un deploy token de projet avec l'accès `write_repository` et stockez-le comme variable CI :
0 commit comments