Re: How to do add-on merge requests and get a pipeline to run?

Dan Eble <[email protected]> writes:

> On 2026-08-18 00:33, David Kastrup wrote:
>> Dan Eble <[email protected]> writes:
> ...
>>> We need to run the regression-test difference detector.  A merge
>>> request should not be labeled Patch::review until someone has recorded
>>> the test differences in the comments.
>> Ok.  I'll have to think about how to get there with reasonable
>> effort.
>
> Two alternatives come to mind:
>
> 1. Run tests on the top of the stack only, relative to master; refer
> reviewers of underlying MRs to the top-of-stack results.  I don't know
> if the workflow definition can tell whether an MR is currently on top,
> and even if it can, another MR could later be added to the stack.
> Maybe this is feasible and maybe it isn't.

Again, this would interfere with the separate reviewability of the
patches.  I think the first in a check should not be kept back by any
others.

> 2. Run on each MR relative to its immediate base.  Speaking for myself
> only, as someone who has a runner in the pool, I wouldn't mind if we
> scripted the checking job so that in a stacked MR, it took time to
> measure the baseline itself instead of downloading an archive of
> prebuilt results.  I'm biased toward donating processing time more
> than network I/O; others might be in a different situation.

That would apply equally to our current situation I think.  If a
particular runner wanted to minimize up/download time, it could be
configured for local production/caching of test baselines.  Are our
baselines minimized reasonably?  I think the usual "make check" does few
actual image comparisons, mostly relying on comparing metrics.

Maybe we should split "make check" into two phases, and the runners use
the output from phase 1 to decide which images to actually download
before starting phase 2?

-- 
David Kastrup