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

On Sat, 2026-08-08 at 22:19 +0200, David Kastrup wrote:
> **Why no pipeline runs now**
> 
> LilyPond's `.gitlab-ci.yml` defines job rules keyed off a named condition:
> 
> ```
> .if-mr-to-default: &if-mr-to-default
>   if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH
> ```
> 
> This is used throughout the config to gate the real test jobs. Since
> !3115 currently targets `dev/dak/bookscopes` rather than `master`,
> `$CI_MERGE_REQUEST_TARGET_BRANCH_NAME` never equals
> `$CI_DEFAULT_BRANCH`, so none of the job rules match and no pipeline is
> created at all [...]

That's lots of words (I cut the rest), but essentially the core of the
"problem": For the moment, we only define jobs for merge requests that
target the master branch.

> **What you could do right now (optional, not required)**
> 
> There isn't a way to make the *real* MR-gated jobs run while the target
> is still a dev branch — that's baked into the rules, not a per-MR
> toggle. The one thing you could try is CI/CD → Pipelines → "Run
> pipeline," manually selecting the `dev/dak/bookoutputblock` branch. That
> creates a `web`-sourced pipeline instead of a `merge_request_event` one,
> and LilyPond's config does have a separate `if-schedule-or-web`
> condition, so depending on which jobs are gated by which condition, this
> might give you (and reviewers) some earlier build/test signal — but it's
> not guaranteed to run the same job set as the eventual MR pipeline

I wouldn't recommend this, it will run "make test" but not "make
check". The currently working approach is to target the master branch,
as Werner suggested. This has been successfully used a number of times
in the past years since we started using GitLab and its CI.

> **For maintainers, for future stacked MRs**

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.

> 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.

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. 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. If you have more changes already submitted, that will only
result in endless conflicts...

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRiF4DLRvon1vw5biCcVOmY/6OEDwUCanuIXAAKCRCcVOmY/6OE
DxvAAPwJ+cYI0bBNN4pPOG1KH7AUo4lGqgkPsa0QgjFq4iRomgD/Sip7r83XguqX
W/kt2vfL+cvS3325aTSSl19XZa55YgI=
=mrjh
-----END PGP SIGNATURE-----