- Types of merge request pipelines
rulesto add jobs
onlyto add jobs
- Use with forked projects
- Available predefined variables
pipelines for merge requests to
merge request pipelines in GitLab 14.8.
You can configure your pipeline 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 merge request pipeline.
- Run when you push a new commit to a branch.
- Are the default type of pipeline.
- Have access to some predefined variables.
- Have access to protected variables and protected runners.
Merge request pipelines:
- Run when you:
- Create a new merge request from a source branch with one or more commits.
- 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 merge request pipelines are configured for the pipeline and the source branch has at least one commit.
- Do not run by default. The jobs in the CI/CD configuration file must be configured to run in merge request pipelines.
- Have access to more predefined variables.
- Do not have access to protected variables or protected runners.
Both of these types of pipelines can appear on the Pipelines tab of a merge request.
The three types of merge request pipelines are:
- Merge request pipelines, which run on the changes in the merge request’s
source branch. Introduced
in GitLab 14.9, these pipelines display a
merge requestlabel to indicate that the pipeline ran only on the contents of the source branch, ignoring the target branch. In GitLab 14.8 and earlier, the label is
- Merged results pipelines, which run on the result of combining the source branch’s changes with the target branch.
- Merge trains, 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.
To use merge request pipelines:
- Your project’s CI/CD configuration file must be configured with jobs that run in merge request pipelines. To do this, you can use:
- You must have at least the Developer role in the source project to run a merge request pipeline.
- Your repository must be a GitLab repository, not an external repository.
You can use the
rules keyword to configure jobs to run in
merge request pipelines. For example:
job1: script: - echo "This job runs in merge request pipelines" rules: - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
You can also use the
workflow: rules keyword
to configure the entire pipeline to run in merge request pipelines. For example:
workflow: rules: - if: $CI_PIPELINE_SOURCE == 'merge_request_event' job1: script: - echo "This job runs in merge request pipelines" job2: script: - echo "This job also runs in merge request pipelines"
You can use the
only keyword with
to configure jobs to run in merge request pipelines.
job1: script: - echo "This job runs in merge request pipelines" only: - merge_requests
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:
Project members in the parent project can trigger a merge request pipeline 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 settings, 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.
/rebasequick action, or Rebase option, no warning displays.
- You must be a member of the parent project and have at least the Developer role.
- The fork project must be visible to the user running the pipeline. Otherwise, the Pipelines tab does not display in the merge request.
To use the UI to run a pipeline in the parent project for a merge request from a fork project:
- In the merge request, go to the Pipelines tab.
- Select Run pipeline. You must read and accept the warning, or the pipeline does not run.
When you use merge request pipelines, you can use:
- All the same predefined variables that are available in branch pipelines.
- Additional predefined variables available only to jobs in merge request pipelines. These variables contain information from the associated merge request, which can be when calling the GitLab Merge Request API endpoint from a job.
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.
In GitLab 13.7 and later,
you can add
workflow:rules to switch from branch pipelines to merge request pipelines.
After a merge request is open on the branch, the pipeline switches to a merge request pipeline.
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 merge request pipeline.
When the configuration syntax is fixed, no further failed pipelines should appear. To find and fix the configuration problem, you can use:
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 merge request pipeline fails.
When using the merge when pipeline succeeds feature and both pipelines types are present, the merge request pipelines are checked, not the branch pipelines.