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?

https://gitlab.kitware.com/utils/ghostflow-director/-/issues/66

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.