1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
---
stage: Verify
group: Pipeline Execution
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Pipelines for merge requests **(FREE)**
You can configure your [pipeline](index.md) to run every time you commit changes to a branch.
This type of pipeline is called a *branch pipeline*.
Alternatively, you can configure your pipeline to run every time you make changes to the
source branch for a merge request. This type of pipeline is called a *pipeline for merge requests*.
Branch pipelines:
- Run when you push a new commit to a branch.
- Are the default type of pipeline.
- Have access to [some predefined variables](../variables/predefined_variables.md).
- Have access to [protected variables](../variables/index.md#protect-a-cicd-variable).
Pipelines for merge requests:
- Run when you:
- Create a new merge request.
- Push a new commit to the source branch for a merge request.
- Select **Run pipeline** from the **Pipelines** tab in a merge request. This option
is only available when pipelines for merge requests are configured for the pipeline.
- Do not run by default. The jobs in the CI/CD configuration file [must be configured](#prerequisites)
to run in pipelines for merge request.
- Have access to [more predefined variables](#available-predefined-variables).
- Do not have access to [protected variables](../variables/index.md#protect-a-cicd-variable).
Both of these types of pipelines can appear on the **Pipelines** tab of a merge request.
## Types of pipelines for merge requests
The three types of pipelines for merge requests are:
- Pipelines for merge requests, which run on the changes in the merge request's
source branch. These pipelines display a `detached` label to indicate that the
pipeline ran only on the contents of the source branch, ignoring the target branch.
- [Pipelines for merged results](pipelines_for_merged_results.md), which run on
the result of combining the source branch's changes with the target branch.
- [Merge trains](merge_trains.md), which run when merging multiple merge requests
at the same time. The changes from each merge request are combined into the
target branch with the changes in the earlier enqueued merge requests, to ensure
they all work together.
## Prerequisites
To use pipelines for merge requests:
- Your project's [CI/CD configuration file](../yaml/index.md) must be configured with
jobs that run in pipelines for merge requests. To do this, you can use:
- [`rules`](#use-rules-to-add-jobs).
- [`only/except`](#use-only-to-add-jobs).
- You must have at least the Developer [role](../../user/permissions.md) in the
source project to run a pipeline for merge requests.
- Your repository must be a GitLab repository, not an [external repository](../ci_cd_for_external_repos/index.md).
## Use `rules` to add jobs
You can use the [`rules`](../yaml/index.md#rules) keyword to configure jobs to run in
pipelines for merge requests. For example:
```yaml
job1:
script:
- echo "This job runs in pipelines for merge requests"
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
```
You can also use the [`workflow: rules`](../yaml/index.md#workflowrules) keyword
to configure the entire pipeline to run in pipelines for merge requests. For example:
```yaml
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
job1:
script:
- echo "This job runs in pipelines for merge requests"
job2:
script:
- echo "This job also runs in pipelines for merge requests"
```
## Use `only` to add jobs
You can use the [`only`](../yaml/index.md#onlyrefs--exceptrefs) keyword with `merge_requests`
to configure jobs to run in pipelines for merge requests.
```yaml
job1:
script:
- echo "This job runs in pipelines for merge requests"
only:
- merge_requests
```
## Use with forked projects
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217451) in GitLab 13.3.
> - [Moved](https://about.gitlab.com/blog/2021/01/26/new-gitlab-product-subscription-model/) to GitLab Premium in 13.9.
External contributors who work in forks can't create pipelines in the parent project.
A merge request from a fork that is submitted to the parent project triggers a
pipeline that:
- Is created and runs in the fork (source) project, not the parent (target) project.
- Uses the fork project's CI/CD configuration, resources, and project CI/CD variables.
Pipelines for forks display with the **fork** badge in the parent project:
### Run pipelines in the parent project **(PREMIUM)**
Project members in the parent project can choose to run a pipeline for merge requests
for a merge request submitted from a fork project. This pipeline:
- Is created and runs in the parent (target) project, not the fork (source) project.
- Uses the CI/CD configuration present in the fork project's branch
- Uses the parent project's CI/CD configuration, resources, and project CI/CD variables.
- Uses the permissions of the parent project member that triggers the pipeline.
Run pipelines in fork project MRs to ensure that the post-merge pipeline passes in
the parent project. Additionally, if you do not trust the fork project's runner,
running the pipeline in the parent project uses the parent project's trusted runners.
WARNING:
Fork merge requests can contain malicious code that tries to steal secrets in the
parent project when the pipeline runs, even before merge. As a reviewer, carefully
check the changes in the merge request before triggering the pipeline. GitLab shows
a warning that you must accept before you can trigger the pipeline.
Parent project members with at least the [Developer role](../../user/permissions.md)
can create pipelines in the parent project for merge requests from a forked project:
1. In the merge request, go to the **Pipelines** tab.
1. Select **Run pipeline**. You must accept the warning, or the pipeline does not run.
## Available predefined variables
When you use pipelines for merge requests, you can use:
- All the same [predefined variables](../variables/predefined_variables.md) that are
available in branch pipelines.
- [Additional predefined variables](../variables/predefined_variables.md#predefined-variables-for-merge-request-pipelines)
available only to jobs in pipelines for merge requests. These variables contain
information from the associated merge request, which can be when calling the
[GitLab Merge Request API endpoint](../../api/merge_requests.md) from a job.
## Troubleshooting
### Two pipelines when pushing to a branch
If you get duplicate pipelines in merge requests, your pipeline might be configured
to run for both branches and merge requests at the same time. Adjust your pipeline
configuration to [avoid duplicate pipelines](../jobs/job_control.md#avoid-duplicate-pipelines).
In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201845),
you can add `workflow:rules` to [switch from branch pipelines to pipelines for merge requests](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines).
After a merge request is open on the branch, the pipeline switches to a merge request pipeline.
### Two pipelines when pushing an invalid CI/CD configuration file
If you push an invalid CI/CD configuration to a merge request's branch, two failed
pipelines appear in the pipelines tab. One pipeline is a failed branch pipeline,
the other is a failed pipeline for merge requests.
When the configuration syntax is fixed, no further failed pipelines should appear.
To find and fix the configuration problem, you can use:
- The [pipeline editor](../pipeline_editor/index.md).
- The [CI lint tool](../lint.md).
### The merge request's pipeline is marked as failed but the latest pipeline succeeded
It's possible to have both branch pipelines and pipelines for merge requests in the
**Pipelines** tab of a single merge request. This might be [by configuration](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines),
or [by accident](#two-pipelines-when-pushing-to-a-branch).
If both types of pipelines are in one merge request, the merge request's pipeline
is not considered successful if:
- The branch pipeline succeeds.
- The pipeline for merge request fails.
When using the [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
feature and both pipelines types are present, the pipelines for merge requests are checked,
not the branch pipelines.
|
