CODEWITHSUNDEEP
gitlabgitlab-ci
Eric Wohnlich
Eric Wohnlich

Reputation: 11

How can I trigger a change on the source branch before merge, during 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:

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.

Upvotes: 0

Views: 41

Answers (1)

KMZ
KMZ

Reputation: 606

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?

Upvotes: 0

Related Questions