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?
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.