GitLab merged results pipeline与merge trains重复触发问题咨询

这两条流水线不属于冗余流程，二者的触发时机、校验目标、覆盖的MR生命周期阶段完全不同，不存在功能重复。

两类流水线的核心定位差异 #

• 合并结果流水线（Merged results pipeline）
  触发节点在MR的评审阶段：只要你往MR推送新提交、或者MR的目标分支有新代码合入，系统就会把当前MR的源分支代码和触发时刻的目标分支最新代码做临时合并，运行流水线校验。
  它的核心作用是给评审环节提供即时的校验反馈：开发者提交代码后立刻就能知道，自己的改动和当前公开的主干代码合并后会不会出编译错误、测试失败，评审人也可以直接参考这个结果判断MR是否具备合入资格，不需要等MR进入合并队列才发现问题，避免无效排队。
• 合并列车流水线（Merge train pipeline）
  触发节点在MR走完所有评审流程、正式加入合并队列之后：这时候系统做临时合并的基准，不是当前公开的目标分支最新代码，而是排在当前MR之前、所有待合入MR全部合并完成后的预期目标分支版本。
  它的核心作用是解决多MR串行合入的冲突问题：从MR过审到真正合入主干的间隙，往往会有多个其他MR先进入队列完成合入，之前跑的合并结果流水线是基于更早的主干版本跑的，没法覆盖前面排队MR带来的代码变动，合并列车流水线就是为了保证最终连续合入后，主干代码一定是经过校验的可用状态。

关于“资源浪费”的说明 #

你觉得重复运行是因为两类流水线都做了“分支合并后的代码校验”，但二者的校验基准、服务阶段完全不一样：前者是评审期的前置校验，解决你的改动和当前公开主干合并有没有问题；后者是合入前的最终校验，解决你的改动和前面排队的所有改动一起合入有没有问题。
对于合入频率低、队列里几乎不会同时排多个MR的项目，确实可能出现两个流水线校验的代码版本几乎一致、结果重复的情况，这种场景下你可以通过配置减少资源消耗：比如调整合并结果流水线的触发规则，设置为MR满足所有合入前置条件（比如获得足够审批、解决完所有评论）之后才触发，或者对非核心分支关闭合并结果流水线，仅保留合并列车校验。
但对于日均合入量高的核心主干分支，这种分层校验反而会整体降低资源消耗：评审阶段就通过合并结果流水线发现的问题，不需要占用合并队列的位置，比排了十几分钟队才在合并列车里发现错误、踢回重改重排队的效率高很多。

内容的提问来源于stack exchange，提问作者Bruce Jeaung