Say I have source branch "foo" that I want to merge into "main". When that is accepted (through the web interface), I would like to update some files on the foo branch before it is merged into main. Is that possible in Gitlab CI/CD or am I limited to only one of:

• pipeline when the MR is created, but not when it is accepted
• pipeline for the merge, which is run after the merge has already happened

I also looked into pre-commit options but that doesn't seem to quite have what I want either (if fast forward is possible pre-merge-commit does not trigger).

Right now I am making a change on the main branch after the merge, with "-ci-skip" to skip that from starting a new pipeline. That works but it means the main branch needs to be writeable by Maintainer (the gitlab runner's role) and I would rather it be that all changes to main have to be through a MR.

Say I have source branch "foo" that I want to merge into "main". When that is accepted (through the web interface), I would like to update some files on the foo branch before it is merged into main. Is that possible in Gitlab CI/CD or am I limited to only one of:

• pipeline when the MR is created, but not when it is accepted
• pipeline for the merge, which is run after the merge has already happened

I also looked into pre-commit options but that doesn't seem to quite have what I want either (if fast forward is possible pre-merge-commit does not trigger).

Right now I am making a change on the main branch after the merge, with "-ci-skip" to skip that from starting a new pipeline. That works but it means the main branch needs to be writeable by Maintainer (the gitlab runner's role) and I would rather it be that all changes to main have to be through a MR.

• gitlab
• gitlab-ci

• why skip ci on main? – Daniel A. White Commented Feb 14 at 21:15
• Because it just ran on main, and I don't want it to infinite loop – Eric Wohnlich Commented Feb 14 at 22:46

1 Answer 1

Why do you want to update the source branch foo after the MR has been accepted? Is it because you want to avoid non-MR main commits?

If yes, I do not think this is possible without hacks of varying dirtyness.

Gitlab offers you the following pipeline types (amother other less relevant ones):

• branch pipelines that are triggered whenever you commit to any branch. These pipelines run in the context of your new commit, regardless whether you pushed it or if it's a merge commit that was created by Gitlab itself.
• MR pipelines that are triggered when you commit to a source branch foo for which there's an open MR. These pipelines run in the context of your pushed commit. Note that this pipeline is triggered NOT ONLY when the MR is opened, but also for every commit into the source brach foo as long as the MR is open.
• Merge results pipeline (Premium/Ultimate feature) that are similar to normal MR pipelines but run in the context of the "would-be merge commit" instead.

When your MR is accepted/closed, Gitlab creates a new commit (merge/ff) on the target branch main, which triggers a normal branch pipeline for that commit on main. Thus, your source branch foo doesn't exist in this context anymore, and you can't access it using Gitlab features.

You can still do a couple of things though:

• you can analyze merge commit info to figure out the source branch of the accepted MR. E.g. this could be done using default Gitlab MR commit message which contains the source branch name.
• you can use git or Gitlab API in your branch pipeline running in the context of the merge commit on main to create a new "fixup" branch based off that merge commit, push your changes, and then open a new MR from that "fixup" branch into main. You can even auto-approve and auto-accept it using the Gitalb API, but be careful to not cause an endless chain of pipelines.
• live with your current solution based on ci-skip. It's not the worst thing really -- we use it for changelog updates, precisely because we didn't find a less clunky way to do it, even though this method introduces "technical" commits. Maybe having a clearly defined and limited set of possible technical commits is a small price to pay for being able to enjoy higher levels of automation?