Review merge train default settings to reduce redundant testing

Created on 9 April 2024, over 1 year ago

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.

Remaining tasks

User interface changes

API changes

Data model changes

📌 Task
Status

Active

Component

gitlab-ci

Created by

🇫🇷France fgm Paris, France

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @fgm
  • Assigned to drumm
  • 🇪🇸Spain fjgarlin

    Note sure if it belongs to https://www.drupal.org/project/infrastructure as it will affect core as well.

  • 🇺🇸United States drumm NY, US

    I believe GitLab used to require merge trains to enable merged results pipelines, so they were a requirement at the time. That requirement looks reversed now, so we could disable merge trains without impact, other than for project maintainer’s workflow.

    Merge trains enable “merge if tests pass,” so maintainers don’t need to think as much about whether recent upstream commits might have changed the results. It is a nice feature, that I expect many maintainers might not know about, since “merge train” doesn’t clearly communicate what it is.

    Combined with testing on git push, it is indeed redundant. Is there a way to skip post-push testing if the commit was a merge that was tested? I suspect there might not be, merging a MR is not too distinguishable from any other push. We can’t skip post-push testing since it is common enough to make commits outside of a MR.

  • 🇪🇸Spain fjgarlin

    There are some variables defined around merge requests here: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predef...

    There is no way to skip push testing if if came from a successful MR, as we cannot get that information.

    There is the variable CI_MERGE_REQUEST_EVENT_TYPE, which can have the values "detached", "merged_result" or "merge_train". So I am not sure if maybe we can do the condition CI_MERGE_REQUEST_EVENT_TYPE != "merge_train". I'm not sure if this is what we'd want though.

  • 🇺🇸United States cmlara

    Untested theory:

    If we solve #3387117: Enable distributed caching in GitLab Runner we could investigate setting all the rules for commits to a branch to default to skip and use a launcher job to trigger the full pipeline if a commit key doesn’t exist in the cache.

    Will not save 100% of the resources (would have to always launch one checker job for commits to the main branch), and makes the workflow a bit more complex Howber should cut down CI time to a fraction of it current usage for those tested through Merge train.

Production build 0.71.5 2024