Review merge train default settings to reduce redundant testing
Problem/Motivation
With the current Gitlab process: when a MR eventually succeeds its pipeline (1), the maintainer starts a “merge train” which then builds again (2). That seems normally pointless, but OK. But then, why is there yet another build (3) after that ?
Steps to reproduce
See e.g. https://git.drupalcode.org/project/xmlrpc/-/pipelines
Proposed resolution
Discussion:
- fjgarlin: guess the actual push to the branch. Isn’t the merge train optional?
- fgm: That’s what happens when you click on “Merge” on an MR. There is no obvious other way to accept an MR, although the UI with the combo button suggests that maybe “Merge” is not the same as “Merge immediately”.
- fgm: Or maybe it’s a build on the main repo instead of the fork ?
- fjgarlin: It seems like we can change behavior per module
- fgm: Sounds like it could cut our CI use by 1/3. But what would the risk be ?
- fjgarlin: No idea to be honest. I don’t know if that’s a gitlab default. Tagging @drumm in case he knows if it’s like that for a reason or not
- moshe: We are definately overspending here. IMO we should disable merge trains by default and let projects use them if they need them.
- drumm: I think when we set this up, merge trains were required to use merged results pipelines. Looks like the requirements are reversed now. Merge trains do allow “merge if tests pass,” which is good, MR tests can get stale. But they are totally redundant with after-commit testing if that’s also running.
