Merge Request Pipelines, Merged Results Pipelines, Merge Trains, and Pre-Merge Validation: Diagnostics, Failure Modes, Security, and Performance

1. Evidence-first diagnostic sequence

Use the same state ordering introduced earlier in the course, with MR identity inserted explicitly:

1. Preserve MR IID, pipeline ID, job IDs, first-failure logs, timestamps, and reports.
2. Confirm pipeline source, exact ref/SHA, MR source/target projects/branches, and event type.
3. Inspect compiled configuration and the workflow/job rules that created/included work.
4. Inspect graph/queue and runner/executor/image identity.
5. Inspect the failing script/tool/network.
6. Inspect reports/artifacts/caches.
7. Inspect mergeability/protected-resource authorization and any external system touched.
8. Apply the least destructive correction and rerun only the smallest safe scope.

2. Failure mode: pipeline tests the wrong ref

Symptom: a developer says “the MR passed,” but the pipeline has source push and ref glci/ch16-feature; the intended MR-specific jobs are absent.

Evidence: pipeline source is push, MR IID/ref variables are absent, and compiled rules show the MR job was omitted. The pipeline may be healthy—it is simply the wrong evidence object.

Repair: configure root workflow:rules or job rules for merge_request_event and make the merge requirement depend on the intended MR pipeline/check rather than a same-named branch result.

3. Failure mode: untrusted fork code reaches parent resources

Symptom: a parent-project member runs a fork MR pipeline in the parent context and the CI diff includes commands that enumerate or transmit sensitive data.

Stop condition: do not run the pipeline merely to “see what happens.” Review CI changes first. Parent-context fork execution can use parent resources/settings and the triggering member’s permissions.

Repair: keep fork execution in the fork for ordinary checks, remove secret requirements from validation, restrict runner/network reachability, and require explicit trusted review before any parent-context execution.

4. Failure mode: duplicate branch and MR pipelines

Symptom: one push to an open MR creates two pipelines with the same source commit: one push, one merge_request_event.

Causal layer: pipeline creation. Look for a broad workflow:rules fallthrough or job rules that admit both sources.

# Broken: the final rule admits many non-MR pipelines.
workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - when: always

# Safer allowlist for this course scenario.
# workflow:
#   rules:
#     - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
#     - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
#     - when: never

Preserve both original pipeline IDs. The duplicate itself is useful evidence that the creation rule was too broad.

5. Failure mode: merged-results assumptions are unavailable

Symptom: documentation or a copied pipeline expects CI_MERGE_REQUEST_SOURCE_BRANCH_SHA/TARGET_BRANCH_SHA to be populated, but they are empty and the pipeline displays as a normal MR pipeline.

Diagnosis: inspect tier and project settings. Those SHAs are documented as populated in merged-results pipelines, not ordinary MR pipelines. On Free, the expected behavior is an ordinary source-only MR pipeline.

Repair: branch logic on the actual event type and feature availability; use the Free local integration simulation when teaching; do not fabricate missing values or downgrade security to obtain them.

6. Failure mode: merge train hides a flaky integration failure

Symptom: a candidate fails once on the train, passes after retry, and the team labels the first failure “transient” without preserving candidate identity or failure signature.

Diagnosis: compare pipeline SHA/event type, job trace, runner identity, test seed/shard data, and queue state. If the candidate changed because the train re-created the integration commit, the two runs are not equivalent evidence.

Repair: quarantine or fix nondeterministic tests with ownership and expiry, preserve first failure, and use bounded retries only for classified transient infrastructure errors.

7. Failure mode: green pipeline but MR still cannot merge

Do not debug the runner. Check merge conflicts, approvals, unresolved discussions, draft state, required checks, branch protection, and train status. A green pipeline is one input to the mergeability decision.

Conversely, if the UI offers merge but the policy expects a particular pre-merge pipeline, verify the requirement configuration rather than assuming GitLab inferred it from job names.

8. Intentionally broken example: wrong-source acceptance

The following configuration appears to “validate everything,” but it allows both branch push and MR pipelines. The release team then reads whichever green pipeline is easiest to find.

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

pre_merge_test:
  image: alpine:3.22.1
  script:
    - test -f src/app.conf

The first rule matches branch pipelines before the MR rule is relevant in that context. The repair is not to rename the job; it is to define which pipeline sources are valid evidence and enforce that at creation time. Then the merge gate can depend on a stable check produced in that intended context.

9. Performance: optimize the correct state

Measure these independently:

10. Security-sensitive actions checklist

• Running fork code in a parent project: privileged trust decision.
• Enabling protected variables/runners for MR pipelines: privileged resource-exposure decision.
• Enabling merged results or merge trains: changes merge validation semantics.
• Changing “pipelines must succeed,” required checks, or branch protection: governance change.
• Skipping/bypassing a merge train: exceptional policy action, not a routine recovery technique.

Document owner, reason, scope, and rollback for each change.

11. Least-destructive recovery map

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.