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

Werner LEMBERG <[email protected]> writes:

>> What I could do is to make the upstream branch master.  MR#2 would
>> consist of exactly the same commits but the runner would start.
>
> Yes.
>
>> But that would make the merge request garbage to review because the
>> diff display would include all the dependencies of branch 3111 that
>> aren't part of this merge request.
>
> Yes.  Mention this situation in the description and tell reviewers to
> ignore the commits that belong to the other MR.
>
> Dan does it this way here and then.
>
>> One needs project maintainer role to set up CI triggers.  As far as
>> I can tell, the pipeline configuration is already the same as with
>> normal merge requests though I don't know what that means with
>> respect to the reference point for "make test-baseline".  But I
>> cannot trigger a pipeline.
>
> Let's see whether somebody else has experience with such a situation.

Well, I asked Claude, and it is often good for plausible-sounding
answers.  Here is what it said.  Now I only need to understand it.

Good news: this isn't a permissions problem, and it's very likely to
resolve itself once !3111 merges — no action needed from you.

**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 — which matches what you're seeing (0 pipelines on the
MR). This is a deliberate design choice in the project's CI config, not
something tied to your role: per GitLab's docs, the Developer role is
already sufficient to trigger merge-request pipelines in the source
project, so role isn't what's blocking you here.

**What should happen automatically once !3111 merges**

When an upstream MR is merged with "delete source branch" and a stacked
MR's target branch is auto-retargeted (here, from `dev/dak/bookscopes`
to `master`), GitLab treats that retarget as a trigger for re-evaluating
the pipeline rules — this behavior was added in GitLab issue
[gitlab-org/gitlab#36995](https://gitlab.com/gitlab-org/gitlab/-/issues/36995)
and is now default (there's even an open request,
[#403608](https://gitlab.com/gitlab-org/gitlab/-/issues/403608), from
teams who'd like to *disable* this because it's now automatic). So once
`dev/dak/bookscopes` is merged into master and !3115's target flips to
`master`, `if-mr-to-default` should evaluate true and a pipeline should
start on its own.

**If it doesn't fire automatically**

Sometimes the auto-retrigger is flaky (see GitLab issue
[#559008](https://gitlab.com/gitlab-org/gitlab/-/work_items/559008) for
a case where it silently didn't happen). If that occurs, as a Developer
you don't need a Maintainer — you can just open the MR's Pipelines tab
and click "Run pipeline," or push an empty commit/rebase the branch,
either of which will re-evaluate the rules against the new target
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, and
it's a manual, one-off run rather than something that updates
automatically on new pushes.

**For maintainers, for future stacked MRs**

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. That's a genuine policy
trade-off (more CI resource use on branches that may be superseded
before they ever reach master) rather than an oversight, so it'd be best
floated on the MR itself or the dev mailing list rather than assumed to
be a bug.

-- 
David Kastrup