Merge Request Pipelines, Merged Results Pipelines, Merge Trains, and Pre-Merge Validation: Concepts, Architecture, and Mental Model

1. The practical problem: “green” is meaningless without the code identity

Chapter 15 coordinated pipelines across projects. Chapter 16 moves the trust boundary back to the moment before code enters an authoritative branch. A merge request can have a green branch pipeline, a green merge request pipeline, a green merged-results pipeline, or a green merge-train pipeline. Those states are not interchangeable because each can evaluate a different Git ref and integration context.

The first question for every pre-merge result is therefore not “did it pass?” but “what exact source revision and integration state did this pipeline evaluate?” Only after that identity is known should you interpret test results, protected-resource access, or mergeability.

2. Mental model: from MR event to mergeability evidence

A merge request is a relationship between source and target branches plus review/approval state. GitLab can build different pipeline views of that relationship. Ordinary MR pipelines validate the source branch content. Merged-results pipelines synthesize a temporary commit that combines source and target. Merge trains go further by validating a candidate together with earlier merge requests in the queue.

            flowchart TD
              A[Merge request event] --> B[Source and target metadata]
              B --> C{Pipeline mode}
              C -->|MR| D[Source branch content]
              C -->|Merged result| E[Temporary source plus target commit]
              C -->|Merge train| F[Temporary queued integration commit]
              D --> G[Checks and reports]
              E --> G
              F --> G
              G --> H[Mergeability evidence]
              H --> I[Merge policy decision]
          

The arrows matter. Pipeline creation is separate from job inclusion; job success is separate from report ingestion; a successful pipeline is separate from approvals, conflicts, merge-train position, and the health of any later deployment.

3. Four pipeline types, four different claims

GitLab documents MR pipelines as source-branch validation: they do not automatically test the target branch content. That is exactly why merged-results pipelines exist. Merge trains solve a different race: two MRs can each integrate with main independently yet conflict when they land close together.

4. The evidence tuple for pre-merge CI

For this chapter, treat the following as one evidence record rather than as unrelated variables:

Do not assume CI_MERGE_REQUEST_SOURCE_BRANCH_SHA is always populated. Current GitLab documents it as empty in ordinary merge request pipelines and populated in merged-results pipelines. The pipeline’s own CI_COMMIT_SHA remains the central identity of what the runner checked out.

5. MR pipelines are opt-in configuration, not a branch-pipeline alias

Branch pipelines can exist with no special rules. Merge request pipelines require the root project configuration to create work for CI_PIPELINE_SOURCE == "merge_request_event". Current GitLab documentation explicitly requires matching rules or workflow:rules in the project’s .gitlab-ci.yml; a matching rule hidden only inside an included component is not enough to satisfy the MR-pipeline prerequisite.

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
    - when: never

validate:
  image: alpine:3.22.1
  script:
    - printf 'source=%s\nsha=%s\n' "$CI_PIPELINE_SOURCE" "$CI_COMMIT_SHA"

This allowlist creates one intentional MR pipeline for an MR update and a separate default-branch pipeline after merge. It does not create a feature-branch push pipeline in parallel with the MR pipeline.

6. MR ref paths and temporary integration commits

Ordinary MR pipelines expose an MR ref path such as refs/merge-requests/1/head through CI_MERGE_REQUEST_REF_PATH. This is useful evidence when later jobs or downstream pipelines need to identify the MR pipeline rather than the latest branch pipeline.

Merged-results pipelines instead build a temporary merged commit generated by GitLab. That commit is not the head of either source or target branch. For audit purposes, record CI_COMMIT_SHA, MR source/target names, and CI_MERGE_REQUEST_EVENT_TYPE together; do not replace the synthetic SHA with the source branch SHA in your evidence.

7. Protected variables and runners are a trust decision

Protected resources are not ordinary configuration convenience. Current GitLab lets maintainers control whether merge request pipelines can access protected CI/CD variables and protected runners. Access is restricted: the source and target branches must both be protected, both must belong to the same project, and the user triggering the pipeline must have the required access to the target branch.

A fork MR cannot satisfy the same-project requirement. This is intentional. Unreviewed code from a fork must not acquire deployment credentials or privileged runner access just because somebody opened a merge request.

8. Fork merge requests change where code and resources come from

By default, an MR from a fork runs its pipeline in the fork project using the fork’s CI configuration, runners, and variables. An authorized member of the parent project can choose to run the MR pipeline in the parent project instead. That changes the resource boundary: the pipeline uses the fork branch’s CI configuration but the parent project’s settings/resources and the triggering member’s permissions.

This can be useful when the fork runner is untrusted, but it is also dangerous: malicious CI changes in the fork can try to exfiltrate parent-project resources. GitLab therefore warns in the UI. The safe operating model is explicit review of CI/configuration changes before any parent-project execution, plus no protected-resource exposure unless all documented requirements are met.

9. Merged results answer an integration question that MR pipelines cannot

An ordinary MR pipeline asks “does this source revision pass?” A merged-results pipeline asks “does a temporary merge of this source revision with the current target pass?” That catches integration defects that do not exist on either branch alone.

Current GitLab places merged-results pipelines in Premium/Ultimate. The mandatory course path must therefore not depend on the feature. You will simulate the same conceptual question locally with a temporary merge in Lesson 2 and label that evidence as a simulation rather than as a GitLab merged-results pipeline.

10. Merge trains add queue context

A merged-results pipeline considers one MR against the target branch. A merge train considers the candidate together with merge requests ahead of it in the queue. That makes the tested integration state dependent on train order. When an earlier MR merges or drops from the train, later candidates can be re-evaluated.

Current GitLab merge trains are Premium/Ultimate and use merged-results pipeline mechanics. The pipeline source remains merge-request-oriented; CI_MERGE_REQUEST_EVENT_TYPE is the more precise signal for detached MR, merged result, or merge-train context.

11. Read-only inspection before changing anything

1. Record project path, MR IID, source project/branch, and target project/branch.
2. Open the pipeline and record pipeline ID, source, ref, SHA, and status.
3. Inspect the compiled configuration and identify the workflow rule that created the pipeline.
4. Record CI_MERGE_REQUEST_EVENT_TYPE and CI_MERGE_REQUEST_REF_PATH when present.
5. Determine whether the source is a same-project branch or a fork.
6. Inspect whether source/target refs are protected and whether protected resources are enabled for MR pipelines—without exposing any secret values.
7. Only then interpret the green/red pipeline as merge evidence.

12. Misconceptions to remove

Knowledge check

Official references and version notes

Documentation verification date: 2026-09-11. Merge-request pipeline behavior, protected-resource access, merged-results pipelines, merge trains, predefined variables, and merge checks are version-sensitive. Re-check the deployed GitLab version and project settings before using these patterns in production.

• Merge request pipelines — prerequisites, source-branch behavior, fork pipelines, parent-project execution, and protected resources.
• Merged results pipelines — temporary merged commits and current Premium/Ultimate availability.
• Merge trains — queue semantics, temporary integration state, current parallel limits, and enforcement options.
• Types of pipelines — branch, MR, merged-results, merge-train, parent/child, and multi-project distinctions.
• Predefined variables reference — MR ref/source/target variables and CI_MERGE_REQUEST_EVENT_TYPE.
• CI/CD YAML syntax reference — authoritative workflow:rules, rules, changes, and job semantics.
• Debugging CI/CD pipelines — CI Lint, compiled configuration, pipeline naming, and evidence-first troubleshooting.
• Protected branches — permissions and CI/CD implications for protected refs.