Checkpoint Lab — Merge Request Pipelines, Merged Results Pipelines, Merge Trains, and Pre-Merge Validation

1. Checkpoint scenario and success criteria

You own a disposable project whose team wants one trustworthy pre-merge signal. The current configuration sometimes creates branch and MR pipelines for the same feature push. Your task is to:

1. create a safe MR validation pipeline on the Free path;
2. predict which pipeline sources should and should not exist;
3. prove the exact MR ref/SHA under test;
4. capture one deliberate duplicate/wrong-source failure;
5. repair only the causal rule;
6. produce a compact evidence packet suitable for review.

2. Current assumptions and preflight

• Documentation verified: 2026-09-11.
• Mandatory feature: ordinary MR pipelines (Free/Premium/Ultimate).
• Optional/simulated: merged-results pipelines and merge trains (Premium/Ultimate).
• Example container image: alpine:3.22.1; record the actual runner/executor/image reported by your job.
• No real secrets, deployments, production runners, or external systems.

Record the disposable project path, default branch, feature branch, current source SHA, and planned MR target before changing CI.

3. Write predictions before running

Write at least these predictions:

1. With the deliberately broken workflow, a feature push with an open MR can create both push and merge_request_event pipelines.
2. After the repair, a feature-branch update creates exactly one MR pipeline; the feature push pipeline is suppressed, while a post-merge default-branch pipeline remains allowed.
3. The successful MR pipeline’s recorded CI_COMMIT_SHA matches the intended feature revision for this ordinary MR pipeline.
4. CI_MERGE_REQUEST_REF_PATH is present in the MR pipeline and absent in the branch pipeline.

4. Phase A — reproduce the bad evidence state

Use this intentionally broad configuration first:

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

stages: [verify]

pre_merge_evidence:
  image: alpine:3.22.1
  stage: verify
  script:
    - mkdir -p evidence
    - printf 'pipeline_id=%s\n' "$CI_PIPELINE_ID" | tee evidence/context.txt
    - printf 'job_id=%s\n' "$CI_JOB_ID" | tee -a evidence/context.txt
    - printf 'source=%s\n' "$CI_PIPELINE_SOURCE" | tee -a evidence/context.txt
    - printf 'sha=%s\n' "$CI_COMMIT_SHA" | tee -a evidence/context.txt
    - printf 'ref=%s\n' "$CI_COMMIT_REF_NAME" | tee -a evidence/context.txt
    - printf 'mr_iid=%s\n' "${CI_MERGE_REQUEST_IID:-none}" | tee -a evidence/context.txt
    - printf 'mr_ref=%s\n' "${CI_MERGE_REQUEST_REF_PATH:-none}" | tee -a evidence/context.txt
    - printf 'event_type=%s\n' "${CI_MERGE_REQUEST_EVENT_TYPE:-none}" | tee -a evidence/context.txt
    - test -f src/app.conf
  artifacts:
    paths: [evidence/context.txt]
    expire_in: 2 days

With an open MR, push one harmless source change. Record both pipeline IDs if both are created. Download or inspect each evidence/context.txt and label one as branch-context evidence and the other as MR-context evidence.

5. Diagnose without deleting either pipeline

Confirm:

• the two pipelines share the same source commit or source-branch update;
• one has source push and no MR ref; the other has source merge_request_event and MR metadata;
• the compiled workflow admits both sources;
• runner capacity is not the cause.

The original branch pipeline is now an evidence artifact for the defect. Keep its ID in your checkpoint notes.

6. Phase B — enforce the intended source contract

Replace only the workflow rules:

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

Keep the evidence job otherwise unchanged. Push another harmless feature commit. Verify that the feature update creates the intended MR pipeline but no parallel feature-branch push pipeline.

7. Prove the successful candidate independently

For the repaired MR pipeline, collect these values from at least two independent locations where possible:

The feature branch name is useful context but not sufficient proof because it can move after the pipeline finishes.

8. Optional integration-state extension

If you have no Premium/Ultimate disposable project, run the local temporary-merge simulation from Lesson 2 and include its source parent, target parent, and simulated merge SHA in the evidence packet under a simulation heading.

If you do have an authorized Premium/Ultimate project, you may instead observe a merged-results pipeline and record its temporary CI_COMMIT_SHA plus event type. Merge-train observation is optional; do not alter a production project merely for the checkpoint.

9. Evidence packet

10. Verification checklist

• The repaired feature update creates one intended MR pipeline.
• The MR pipeline source is merge_request_event.
• The MR IID/ref evidence is present and the pipeline SHA is recorded.
• The old duplicate pipeline remains identifiable in notes as first-failure evidence.
• No protected variable or production runner was required.
• Any merged-result behavior is either truly observed in an authorized Premium/Ultimate project or explicitly labeled as simulation.
• Pipeline success is not claimed as proof of deployment/external health.

11. Cleanup/rollback

1. Close the disposable MR after capturing the final evidence.
2. Delete the local simulation worktree if used.
3. Delete only the exact disposable feature branch/project after checking identity.
4. If optional merged-results/train settings were changed in a disposable project, restore the prior setting and note the rollback.
5. Do not bulk-delete pipelines or artifacts; preserve the checkpoint evidence until review is complete.

12. What Chapter 16 adds to the production operating model

You can now distinguish source-branch success from integrated-candidate success, prove the exact commit/ref under test, keep fork code outside privileged resource boundaries, avoid duplicate pipeline creation, and interpret merged-results/merge-train evidence without confusing it with deployment health or governance approval.

Chapter 17 builds on this identity discipline when one logical test suite expands into many parallel jobs and matrix combinations. Parallelism is useful only if every shard still belongs to the same well-defined source/integration candidate and its evidence can be recombined without ambiguity.

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.