Commit 68a33966 authored by Marcel Amirault's avatar Marcel Amirault

Clarify doubled pipelines issue

Add screenshots to make it clearer if the user
is impacted by the issue, and attempt to simplify
or clarify certain details.
parent c47ff7d4
...@@ -258,55 +258,55 @@ For example, with this `.gitlab-ci.yml` configuration: ...@@ -258,55 +258,55 @@ For example, with this `.gitlab-ci.yml` configuration:
test: test:
script: ./test script: ./test
rules: rules:
- if: $CI_MERGE_REQUEST_ID # Include this job in a pipeline for merge request - if: $CI_MERGE_REQUEST_ID # Include this job in pipelines for merge request
- if: $CI_COMMIT_BRANCH # Include this job in a branch pipeline - if: $CI_COMMIT_BRANCH # Include this job in all branch pipelines
# Or, if you are using the `only:` keyword: # Or, if you are using the `only:` keyword:
# only: # only:
# - merge_requests # - merge_requests
# - branches # - branches
``` ```
Two pipelines are created. Two pipelines are created when you push a commit to a branch that also has a pending
merge request:
1. A branch pipeline that runs for the branch. - A merge request pipeline that runs for the changes in the merge request. In
1. A merge request pipeline that runs for the merge request. **CI/CD > Pipelines**, the merge request icon (**{merge-request}**)
and the merge request ID are displayed. If you hover over the ID, the merge request name is displayed.
![MR pipeline icon example](img/merge_request_pipelines_doubled_MR_v12_09.png)
The branch pipeline runs for the changes pushed to the branch, and doesn't have a direct - A "branch" pipeline that runs for the commit pushed to the branch. In **CI/CD > Pipelines**,
relationship with any merge request. It's mainly used for static branches like `master`, the branch icon (**{branch}**) and branch name are displayed. This pipeline is
rather than feature branches that exist for a limited time. GitLab triggers this created even if no merge request exists.
kind of pipeline **when you push a new commit to a branch**.
The pipeline for merge requests runs on the changes in a specific merge request. ![branch pipeline icon example](img/merge_request_pipelines_doubled_branch_v12_09.png)
It's mainly used for feature branches that are created with at least one merge request,
rather than a static branch. GitLab triggers this kind of pipeline
**when a merge request is created or updated**.
There is overlap between these events. When you push a new commit to a feature branch, With the example configuration above, there is overlap between these two events.
**GitLab tries to create both kinds of pipelines**. When you push a commit to a branch that also has an open merge request pending,
both types of pipelines are created.
You must explicitly define which job should run for which purpose. To fix this overlap, you must explicitly define which job should run for which
purpose, for example:
To fix the example above, limit the job to only run on specific branches like `master`, and
not feature branches that will have merge requests:
```yaml ```yaml
test: test:
script: ./test script: ./test
rules: rules:
- if: $CI_MERGE_REQUEST_ID # Include this job in a pipeline for merge request - if: $CI_MERGE_REQUEST_ID # Include this job in pipelines for merge request
- if: $CI_COMMIT_BRANCH == 'master' # Include this job in a master pipeline - if: $CI_COMMIT_BRANCH == 'master' # Include this job in master branch pipelines
``` ```
This effectively resolves the overlap by excluding the branch pipeline job from feature These `rules:` must be added to jobs that could be added to both types of pipelines. Alternatively,
branches, and should be done for all jobs that could be added to both types of pipelines. you can use the [`workflow:`](../yaml/README.md#exclude-jobs-with-rules-from-certain-pipelines)
parameter to add the rules all jobs globally.
To enable this globally, you can use the [`workflow:`](ci/yaml/README.md#exclude-jobs-with-rules-from-certain-pipelines)
parameter to enable this for all jobs at once.
### Two pipelines created when pushing an invalid CI configuration file ### Two pipelines created when pushing an invalid CI configuration file
As described above, pushing a commit to a merge request triggers the creation of two types of Similar to above, pushing to a branch with an invalid CI configuration file can trigger
pipelines. In rare cases, duplicate pipelines can be created. the creation of two types of failed pipelines. One pipeline is a failed merge request
pipeline, and the other is a failed branch pipeline, but both are caused by the same
invalid configuration.
In rare cases, duplicate pipelines are created.
See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/201845) for details. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/201845) for details.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment