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

Jonas Hahnfeld <[email protected]> writes:

> I first had to look up stacked merge requests, and it's a relatively
> recent feature available since GitLab 19.1 in June. So not surprising
> that the CI configuration, whose core idea of testing merge requests
> has survived for more than 6 years, doesn't know how to deal with it.

Ah, I wasn't aware of that.  I just looked whether I could specify a
different branch to target, saw that I could, and did it.  Seemed
natural.  That I was exercising something quite new wasn't clear to me.

>> If this kind of "MR onto another MR's branch" workflow is going to be
>> common (which it sounds like it is, for staged LilyPond refactors),
>> it's worth raising with a Maintainer whether `.gitlab-ci.yml` should
>> be relaxed — e.g., also allow pipelines when the target branch name
>> matches a `dev/...` pattern that itself has an open MR to master, or
>> gate an opt-in via a label a reviewer can apply.
>
> We can change the configuration to create pipelines for all merge
> requests, but the question is which jobs to run. In particular "make
> check" is tricky because we run "make baseline" only for commits in
> master.

Well, that would be possible as well.  It would have the disadvantage of
not separating the artifacts of the second MR from the first one.

> Also there is the more fundamental question: Do we actually want to
> use stacked merge requests? So far, we used the approach that Werner
> described of "duplicating" commits in multiple merge requests, all
> targeting master.

If "we used the approach", obviously there is a need for exactly that.

> In my personal opinion, this is (or should be) a rather exceptional
> case since incremental development should be incrementally submitted
> and reviewed, at a sustainable pace, and with the possibility of
> incorporating review feedback from earlier merge requests.

I am not suggesting that the pacing of countdowns should be sped up.
But it seems pointless to either

a) Make large MRs that are not well reviewable because they include
changed from two sequential MRs

b) hide an MR from review until the last MR is accepted.  In particular
when the second MR addresses a shortcoming of the first MR (possibly
blocking its acceptance) without sharing a lot of code.  A kind of
"retconning".

> If you have more changes already submitted, that will only result in
> endless conflicts...

Stacking MRs actually seem like a reasonable way to keep the number of
conflicts down over having diverging commits in two separate MRs one of
which is the base for another.

-- 
David Kastrup