Merge Trains broken when Semi-Linear History is used.
The current implementation of Merge Trains is broken when "Merge commit with semi-linear histroy" option is selected for the Merge method. As it stands now if you have both that option and "Merge pipelines will try yo validate post-merge result prior to merging" configured, Gitlab will allow the creation of merge trains. However, because of the semi-linear requirement, all but the first MR will fail. This allows multiple builds to be started but will cause all but the first to fail due to needing a rebase.
Option 1 (less desireable): Disable merge trains if semi-linear is enabled. Option 2: If the rebase is clean, then start the pipeline assuming the commit before it passed (as it does now), but include the rebase. If the rebase is not clean, remove that MR from the train and update so the developer can fix it.
Intended users
This feature will mainly be used by Release Managers and maintainers of CI/CD resources by cutting down on wasted build.
Further details
Proposal
This should not change the workflow, I would think, except by maybe adding a warning when checking the merge option to be semi-linear that would say something like "since you are using a semi-linear history, merge requests may be rebased automatically"
Permissions and Security
No Permission changes are necessary.
Documentation
The Merge Trains documentation should be updated with a note that automatic rebases may occur if using semi-linear history.
Testing
What does success look like, and how can we measure that?
When both these options are checked, a merge train can be started with 2 different MR's against the same branch. If the second is a clean rebase, then upon success of the pipelines both would get merged in.
What is the type of buyer?
Premium (I believe that is where Merge Trains exist)