GitLab-CI：为什么合并结果管道会构建两次未更改的结果？

Question

我正在试用 GitLab 的“终极”版本，特别是合并结果管道功能以及相关的合并列车功能。

我为我的项目启用了合并结果管道和合并列车，合并方法设置为合并提交，并且.gitlab-ci.yml根据文档，我的规则有以下规则：

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

这一切似乎都很顺利，但有一件事我不明白。

想象一下，只有一个打开的合并请求，并且main自创建相关分支以来目标分支上没有发生任何更改。当我推送到 MR 分支时，我期望运行“合并结果”管道，据我了解，这是目标分支与我的 MR 分支的抢先合并。管道成功，MR 现在有资格添加到合并列车中。

如果我确实将其添加到合并列车中，它会再次构建，我必须等待它完成才能合并。为什么这是必要的？它已经构建了合并的结果，此后没有任何变化，这是可以检测到的，那么为什么效率低下呢？

这导致我的团队希望使用“立即合并”按钮而不是添加到合并列车，以避免多余的管道（以及由此产生的等待实际合并发生的情况）。我不希望这成为一种习惯，因为它违背了这两个功能的目的。

以前我们只使用仅 FF 的分支管道，尽管不断重新设置或合并目标很痛苦，但至少如果构建是绿色的并且没有任何更改，则合并可以立即发生。

也许我的配置遗漏了一些东西？

Answer 1

这是因为合并结果管道和合并列车是两个独立的事件。GitLab 会自动检测合并列车中的冗余管道，并自动取消这些冗余管道。

但是，如果您将 MR 添加到合并列车中，并说它依赖于另一个 MR，则正在构建的内容与“合并结果”管道不同，因为还必须添加列车中其他 MR 的引用。

根据您描述的场景，合并列车管道实际上并不冗余，因此不会自动取消。

还值得注意的是，对合并列车的快进合并支持是合并列车的计划功能，以使它们更加高效。