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?