我正在试用Gitlab的“终极”版本，特别是功能，以及相关的 Merge Trains> Merge Trains 功能。
我有合并结果管道＆amp;根据文档，根据文档，Merge Method启用了Merge Trains启用我的项目，合并方法将合并提交，我的 .gitlab-ci.yml 具有以下规则：
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
这一切似乎都可以很好地工作，但是有一个规则，但是有一个规则我不明白的事情。
想象一下，只有一个开放的合并请求，并且由于创建了相关分支，因此目标分支没有任何更改。当我推到MR分支机构时，我希望“合并结果”管道运行，据我了解，这是目标分支与我的MR分支机构的先发制人合并。管道成功，MR现在有资格加入合并火车。
而且，如果我确实将其添加到合并列车中，它将再次构建，我必须等待它完成，然后才能合并。为什么需要这？它已经建立了合并的结果，此后什么都没有改变，这是可以检测到的，那么为什么效率低下呢？
这导致我的团队希望使用“立即合并”按钮，而不是添加合并列车，以避免使用多余的管道（以及由此产生的等待实际合并发生）。我不希望这成为一种习惯，因为它破坏了这两个功能的目的。
以前，我们只是使用了仅FF的分支管道，尽管不断反弹或合并目标是很痛苦的，但至少如果构建是绿色的，没有任何改变，但合并可能立即发生。
也许我缺少配置的东西？
I'm trialing the "Ultimate" version of GitLab, in particular the Merge Results Pipeline feature, along with the related Merge Trains feature.
I have Merge Results pipeline & Merge Trains enabled for my project, Merge Method is set to Merge Commit, and my .gitlab-ci.yml has the following rules, as per the docs:
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
This all seems to work nicely, but there's one thing I don't understand.
Imagine there is just one open Merge Request, and there have been no changes on the target branch main since the related branch was created. When I push to the MR branch, I expect a "merge results" pipeline to run, which as I understand it is a preemptive merge of the target branch with my MR branch. The pipeline succeeds, and the MR is now eligible to add to the Merge Train.
And if I do add it to the Merge Train, it builds again and I must wait for this to complete before it can be merged. Why is this necessary? It has already built the result of the merge, and nothing has changed since, and this is detectable, so why the inefficiency?
This leads to my team wanting to use the "Merge Immediately" button instead of adding to the Merge Train, to avoid the superfluous pipeline (and the resulting wait for the actual merge to happen). I don't want this to become a habit since it defeats the purpose of these two features.
Previously we just used FF-only branch pipelines and although it was painful to constantly rebase or merge the target, at least if the build was green and nothing had changed, the merge could happen immediately.
Perhaps I'm missing something with my configuration?
发布评论
评论（1）
这是因为合并结果管道和合并列车是两个单独的事件。 gitlab确实会自动
但是，如果将MR添加到合并火车中，说这取决于另一个MR，则构建的内容不是与“合并结果”管道相同的，因为也必须添加火车。
根据您所描述的方案，合并火车管道实际上并不是冗余，因此不会自动取消。
还值得一提是合并火车的计划中的功能，以提高它们的效率。
This is because the merge result pipeline and merge train are two separate events. GitLab does automatically detect redundant pipelines in merge trains and automatically cancels those redundant pipelines.
However, if you add your MR to a merge train by saying it depends on another MR, what is being built is not the same as the "merged result" pipeline because the refs from the other MRs in the train must be added as well.
Based on your described scenario, the merge train pipeline is not actually redundant and therefore is not automatically cancelled.
It is also worth noting that Fast-forward merge support for merge trains is a planned feature for merge trains to make them more efficient.