[PP-1] MR retesting with GitLab CI

The more I think about this, potentially the less there is to actually do here since more of it is baked into gitlab. Possibly nothing, however I opened 📌 Mark issues needs work when MRs can't be merged or pipelines fail Active and postponing on that.

Discussing more in slack:

When MRs are tested, we test them merged with the target branch, so we're always testing the result as if they'd just been merged. So if an MR is being committed to but hasn't been brought up to speed with HEAD for a while, it's still tested against HEAD so that doesn't matter.

If an MR isn't mergeable, gitlab detects this without a CI run and warns you.

The remaining thing then is the situation when an issue is RTBCed when the last MR run was weeks ago (which happens quite often), or stays RTBC for a long time without a new MR run (which also happens quite often). This is probably handled by using the gitlab rebase button manually.

So I think the only question then is would we want to set up some kind of auto-fast-forward rebase of MRs that are old but still apply. Maybe not.

When using GitLab’s merge UI, there is the capability for maintainers to “merge if pipelines pass” https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html

I believe the main drawbacks of GitLab’s merge UI for core are:

• Git commit authorship is set to the merge request author. There are a number of GitLab issues about this, starting from https://gitlab.com/gitlab-org/gitlab/-/issues/26902
• GitLab’s commit message templating won’t have an option for a list of usernames

Would be relatively easy automation thats generic so a google search yields example code:

1. https://gitlab.com/gitlab-org/gitlab-foss/-/issues/18834
2. https://how-to.dev/how-to-autorebase-mrs-in-gitlab-ci
3. https://medium.com/ovrsea/how-to-automatically-rebase-all-your-merge-req...

RTBC retesting on DrupalCI was expensive. If I recall correctly, 20% of all compute for DrupalCI at times, highly dependent on the RTBC queue.

If we were to rebase every MR on every commit, and run pipelines, that would be incredibly wasteful, expensive, and a lot of junk to read through in the MR activity.

If a MR can be automatically rebased without conflicts, it probably does not need a rebase. The pipelines already test the merged result with upstream commits at the time. Viewing the MR page will tell you if there are merge conflicts and a manual rebase is needed.

In my view, the missing piece is committers knowing that tests still pass as they merge.

In my view, the missing piece is committers knowing that tests still pass as they merge.

Yes it happens pretty rarely but it can be very confusing when it does. Being able to use merge trains seems like the ideal end point, but we are still downloading the diff with curl and committing locally, so quite a long distance.