diff options
| -rw-r--r-- | doc/ci/triggers/README.md | 24 | ||||
| -rw-r--r-- | doc/ci/triggers/img/triggers_page.png | bin | 5116 -> 110560 bytes | |||
| -rw-r--r-- | doc/user/project/new_ci_build_permissions_model.md | 10 |
3 files changed, 26 insertions, 8 deletions
diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md index ccaee33dc92..e380282f910 100644 --- a/doc/ci/triggers/README.md +++ b/doc/ci/triggers/README.md @@ -4,6 +4,7 @@ - [Introduced][ci-229] in GitLab CE 7.14. - GitLab 8.12 has a completely redesigned job permissions system. Read all about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#job-triggers). +- GitLab 9.0 introduced a trigger ownership to solve permission problems. Triggers can be used to force a rebuild of a specific `ref` (branch or tag) with an API call. @@ -21,13 +22,30 @@ overview of the time the triggers were last used.  +## Take ownership + +Each created trigger when run will impersonate their associated user including +their access to projects and their project permissions. + +You can take ownership of existing triggers by clicking *Take ownership*. +From now on the trigger will be run as you. + +## Legacy triggers + +Old triggers, created before 9.0 will be marked as Legacy. Triggers with +the legacy label do not have an associated user and only have access +to the current project. + +Legacy trigger are considered deprecated and will be removed +with one of the future versions of GitLab. + ## Revoke a trigger You can revoke a trigger any time by going at your project's **Settings > Triggers** and hitting the **Revoke** button. The action is irreversible. -## Trigger a job +## Trigger a pipeline > **Note**: Valid refs are only the branches and tags. If you pass a commit SHA as a ref, @@ -63,7 +81,7 @@ below. See the [Examples](#examples) section for more details on how to actually trigger a rebuild. -## Trigger a job from webhook +## Trigger a pipeline from webhook > Introduced in GitLab 8.14. @@ -117,7 +135,7 @@ curl --request POST \ "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline?token=TOKEN&ref=master" ``` -### Triggering a job within `.gitlab-ci.yml` +### Triggering a pipeline within `.gitlab-ci.yml` You can also benefit by using triggers in your `.gitlab-ci.yml`. Let's say that you have two projects, A and B, and you want to trigger a rebuild on the `master` diff --git a/doc/ci/triggers/img/triggers_page.png b/doc/ci/triggers/img/triggers_page.png Binary files differindex 8ebf68d0384..eafd8519a23 100644 --- a/doc/ci/triggers/img/triggers_page.png +++ b/doc/ci/triggers/img/triggers_page.png diff --git a/doc/user/project/new_ci_build_permissions_model.md b/doc/user/project/new_ci_build_permissions_model.md index b559d132590..55610a7b014 100644 --- a/doc/user/project/new_ci_build_permissions_model.md +++ b/doc/user/project/new_ci_build_permissions_model.md @@ -87,12 +87,12 @@ your Runners in the most possible secure way, by avoiding the following: By using an insecure GitLab Runner configuration, you allow the rogue developers to steal the tokens of other jobs. -## job triggers +## Pipeline triggers -[job triggers][triggers] do not support the new permission model. -They continue to use the old authentication mechanism where the CI job -can access only its own sources. We plan to remove that limitation in one of -the upcoming releases. +Since 9.0 [pipelnie triggers][triggers] do support the new permission model. +The new triggers do impersonate their associated user including their access +to projects and their project permissions. To migrate trigger to use new permisison +model use **Take ownership**. ## Before GitLab 8.12 |
