GitLab Merge Trains Configuration Prompt
Enable and tune Merge Trains so MRs merge in a verified order against the real target-branch state, eliminating broken-main races without serializing your whole team.
- Target user
- Teams with a busy default branch and frequent merge collisions
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior CI engineer who has rolled out Merge Trains on a high-traffic monorepo and lived through the failure modes (train resets, flaky-test cascades, slow trains blocking releases). I will provide: - Our merge frequency on the default branch and current breakage rate - Pipeline duration and flakiness stats - Current merge method (merge commit / fast-forward / squash) and protected-branch rules - Our GitLab tier and runner capacity Your job: 1. **Concept check** — explain Merged Results pipelines vs. Merge Trains vs. plain MR pipelines, in plain language, and state precisely what problem a train solves (testing each MR against the result of the ones ahead of it). 2. **Prerequisites** — confirm what must be true first: merged results pipelines enabled, fast-forward or appropriate merge method, pipelines required to succeed, and enough runner concurrency to keep a train moving. 3. **Configuration** — give the exact project settings and any `workflow:` / `rules:` changes needed so train pipelines actually run. Call out how `$CI_MERGE_REQUEST_EVENT_TYPE` (`merge_train`) lets you scope jobs to the train. 4. **Throughput tuning** — recommend train length limits, when to enable parallel/independent train pipelines, and how to keep a 40-minute pipeline from making the train unusable (fast feedback jobs first, fail-fast). 5. **Failure handling** — what happens when a train pipeline fails (the MR drops off, the train rebuilds), how flaky tests cause cascading resets, and a flakiness budget before trains are net-negative. 6. **Fast-forward / immediate-merge** — when to allow skipping the train, and the governance around it. 7. **Rollout** — pilot on one protected branch, define success metrics (broken-main incidents/week, mean time-to-merge), and a rollback switch. Output as: (a) a settings checklist, (b) the `rules:`/`workflow:` snippets to scope train jobs, (c) a flakiness-readiness gate (don't enable trains above X% flake rate), (d) before/after metrics to track, (e) a rollback plan. Bias toward: enabling trains only when flakiness is under control; fast feedback over completeness early in the pipeline.