合并请求流水线是什么
以合并后的结果为准验证变更：GitLab 的合并请求事件管道（merge_request_event）针对合并结果运行，GitHub 的 pull_request 事件默认对合并视图验证，通过后合并按钮才可点。它解决的是分支各自全绿、合并后主干变红的两段式问题：验证对象从分支头换成合并产物，语义冲突（两边各自能过、合起来编译失败）在合并前暴露。配套机制是分支保护：要求该检查通过后才允许合并。
基本信息
| 价值 | 防止分支全绿、合并后主干红 |
|---|---|
| 验证对象 | 合并结果，而非仅分支头 |
| 配套 | 分支保护要求该检查通过后才允许合并 |
| 触发示例 | GitLab merge_request_event、GitHub on pull_request |
| 安全边界 | fork 贡献的 PR 默认不拿到密钥，设计要以此为前提 |
典型使用场景
- 主干保护：要求 MR 检查通过才可合并，杜绝带病合入。
- 多人并行开发：每个 MR 独立验证合并结果，提前发现语义冲突。
- 评审联动：评审意见与流水线结果在同一界面，评审者直接看到验证结论。
- 流水线去重：推送触发与 MR 触发并存时收敛配置，配合取消策略避免同一提交跑两遍。
- 分层检查：轻量检查放 MR，重量级全量回归放主分支或夜间任务。
- 合并队列：高流量仓库用合并队列在合并前重验（GitLab 合并列车、GitHub merge queue），降低主干红灯概率。
- 外部贡献流程：fork 下的 PR 先跑无密钥检查，维护者批准后再进入需要凭据的阶段。
GitLab 配置
GitLab 配置
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCHGitHub 配置
GitHub 配置
on:
pull_request:
branches: [main]pull_request 与 push 两种触发的验证对象不同：前者是合并结果，后者是分支头；两者同时启用时要理解同一提交为什么跑了两条流水线。
fork 仓库的 PR 默认不向发起方暴露密钥：需要密钥的阶段应设计为维护者批准后运行，别把它当默认可用。
作业重命名后分支保护里引用的检查名可能失效：合并门禁静默消失，改名要同步更新保护规则。