Testing merge requests

should we recommend use Do: test --merged when testing older branches esp. those that are being backported to the release? I suspect that is one the reasons why dashboards are taking too long of late.

That should improve testing turnaround time, I think.

For backported branches, yes. Basically anything older than 100 or so commits would probably benefit from it.

Tbh we may want to make it the default and add a command to actually run as not-merged for the odd cases where it may be necessary.

The logic for --merged is in this repo. Please file an issue.

Note that one downside to --merged is that buildbot now no longer knows your source branch name in the buildbot.kitware.com grid (it is refs/test/release/6629/heads/1 where 6629 is the MR number and 1 means it is the second merge-test of the MR). CDash has the real name though.

I’ll note that gitlab-ci does not run merged tests by default for MR testing. We’d need Do: test to interact with gitlab-ci first (nb. we need that anyways for Backport testing too).

Though this might be slightly off-topic, I’m wondering exactly what “Backport: release” does.

Does it simply merge the MR into release, and then merge release into master?


Not quite. It merges the MR HEAD commit into the target branch, any backport branch gets the same. So you get a graph that looks like this:

 -- M - M - M (master)
       /   /
      T   /
     / \ /
 -- R - R (release)

Where T is merged independently into master and release. As part of making release always reachable from master, there is then a git merge -s ours release done on master. This is then pushed all-as-one to the main repository using git push --atomic.

Note that T might be different for each backport target branch from a single MR (e.g., Backport: release:HEAD^2) which is why, in general, separate merges are necessary (rather than merging once then cascading the branches together via merges that way).

Various branch/MR topologies for different situations: https://gitlab.kitware.com/utils/git-workflow/-/wikis/Backport-topics
Implementation of the logic to do the backports: https://gitlab.kitware.com/utils/rust-ghostflow/-/tree/master/ghostflow%2Fsrc%2Factions%2Fmerge

Thanks, Ben, that wiki page on backports clears things up a lot. Nice contribution.