diff options
Diffstat (limited to 'doc/ci/jobs')
-rw-r--r-- | doc/ci/jobs/ci_job_token.md | 5 | ||||
-rw-r--r-- | doc/ci/jobs/job_control.md | 43 |
2 files changed, 26 insertions, 22 deletions
diff --git a/doc/ci/jobs/ci_job_token.md b/doc/ci/jobs/ci_job_token.md index 532a0dffbce..1906d9cdb6c 100644 --- a/doc/ci/jobs/ci_job_token.md +++ b/doc/ci/jobs/ci_job_token.md @@ -24,7 +24,10 @@ You can use a GitLab CI/CD job token to authenticate with specific API endpoints - [Terraform plan](../../user/infrastructure/index.md). The token has the same permissions to access the API as the user that executes the -job. Therefore, this user must be assigned to [a role that has the required privileges](../../user/permissions.md#gitlab-cicd-permissions). +The token has the same permissions to access the API as the user that caused the +job to run. A user can cause a job to run by pushing a commit, triggering a manual job, +being the owner of a scheduled pipeline, and so on. Therefore, this user must be assigned to +[a role that has the required privileges](../../user/permissions.md#gitlab-cicd-permissions). The token is valid only while the pipeline job runs. After the job finishes, you can't use the token anymore. diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md index 596df34b5c2..a2406a68bb2 100644 --- a/doc/ci/jobs/job_control.md +++ b/doc/ci/jobs/job_control.md @@ -404,10 +404,7 @@ build: If you change multiple files, but only one file ends in `.md`, the `build` job is still skipped. The job does not run for any of the files. -Read more about how to use `only:changes` and `except:changes`: - -- [New branches or tags *without* pipelines for merge requests](#use-onlychanges-without-pipelines-for-merge-requests). -- [Scheduled pipelines](#use-onlychanges-with-scheduled-pipelines). +With some configurations that use `changes`, [jobs or pipelines might run unexpectedly](#jobs-or-pipelines-run-unexpectedly-when-using-changes) #### Use `only:changes` with pipelines for merge requests @@ -459,22 +456,6 @@ it doesn't matter that an earlier pipeline failed because of a change that has n When you use this configuration, ensure that the most recent pipeline properly corrects any failures from previous pipelines. -#### Use `only:changes` without pipelines for merge requests - -Without [pipelines for merge requests](../pipelines/merge_request_pipelines.md), pipelines -run on branches or tags that don't have an explicit association with a merge request. -In this case, a previous SHA is used to calculate the diff, which is equivalent to `git diff HEAD~`. -This can result in some unexpected behavior, including: - -- When pushing a new branch or a new tag to GitLab, the policy always evaluates to true. -- When pushing a new commit, the changed files are calculated by using the previous commit - as the base SHA. - -#### Use `only:changes` with scheduled pipelines - -`only:changes` always evaluates as true in [Scheduled pipelines](../pipelines/schedules.md). -All files are considered to have changed when a scheduled pipeline runs. - ### Combine multiple keywords with `only` or `except` If you use multiple keywords with `only` or `except`, the keywords are evaluated @@ -777,7 +758,7 @@ job1: - echo rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" - - if: $CI_PIPELINE_SOURCE == "scheduled" + - if: $CI_PIPELINE_SOURCE == "schedule" - if: $CI_PIPELINE_SOURCE == "push" when: never ``` @@ -943,3 +924,23 @@ For example: - `($VARIABLE1 =~ /^content.*/ || $VARIABLE2) && ($VARIABLE3 =~ /thing$/ || $VARIABLE4)` - `($VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/) && $VARIABLE3` - `$CI_COMMIT_BRANCH == "my-branch" || (($VARIABLE1 == "thing" || $VARIABLE2 == "thing") && $VARIABLE3)` + +## Troubleshooting + +### Jobs or pipelines run unexpectedly when using `changes:` + +You might have jobs or pipelines that run unexpectedly when using [`rules: changes`](../yaml/index.md#ruleschanges) +or [`only: changes`](../yaml/index.md#onlychanges--exceptchanges) without +[pipelines for merge requests](../pipelines/merge_request_pipelines.md). + +Pipelines on branches or tags that don't have an explicit association with a merge request +use a previous SHA to calculate the diff. This calculation is equivalent to `git diff HEAD~` +and can cause unexpected behavior, including: + +- The `changes` rule always evaluates to true when pushing a new branch or a new tag to GitLab. +- When pushing a new commit, the changed files are calculated by using the previous commit + as the base SHA. + +Additionally, rules with `changes` always evaluate as true in [scheduled pipelines](../pipelines/schedules.md). +All files are considered to have changed when a scheduled pipeline runs, so jobs +might always be added to scheduled pipelines that use `changes`. |