Azure DevOps Pipeline not triggering when merge-commit contains a [skip ci] commit

Question

Context

Our pipeline triggers:

trigger:
  branches:
    include:
      - develop
      - master

pr:
  - master

Our pipeline acts based on some conditions which check which branch it's on, or what triggered the pipeline.

• Commit to develop triggers bumps the version, commits back to develop, builds and artifacts
• PR triggers a deployment to acceptance
• Commit to master triggers a deployment to production

To not have the develop branch trigger itself it commits with [skip ci] in the commit message.

I have verified that it works when I merge a PR that does not contain any [skip ci] commits. So the trigger itself is functional.

---

Problem

When we merge the PR to master it does NOT trigger the CI trigger at all. In the azure devops panel it never shows up, indicating that it is ignored.

Removing the [skip ci] commit makes this problem go away, but introduces the problem of the pipeline triggering itself constantly.

Our repository is in GitHub, preventing me from manually filtering out based on commit author or something.

I'm somewhat perplexed that a merge commit, containing an older commit with [skip ci] in it, is preventing the trigger from firing.

Am I misunderstanding expected behavior here?

I'm open to workarounds as well.

Apologies if this is answered somewhere already, but I could not find anyone with this exact issue.

---

Commit log

In red: a merged PR without a [skip ci] commit -- this correctly triggers CI master branch (see underlined commit with checkmark)

In yellow: a merged with a [skip ci] commit -- this does not trigger CI master branch (see underlined commit without checkmark)

Neither merge commits contain more then the title in the commit message.

---

Azure DevOps Pipeline log

I've marked the same sections as in the github screenshot for clarity. As you can see an Individual CI for master is missing in the yellow section.

Answer 1

When we merge the PR to master it does NOT trigger the CI trigger at all. In the azure devops panel it never shows up, indicating that it is ignored.

I could almost reproduce this issue on my side with Github repo.

If we set the trigger for the main pipeline like:

trigger:
  branches:
    include:
      - develop
      - main

pr:
  - main

In order to avoid CI trigger from develop branch, we add [skip ci] in the commit message when commit for develop:

Obviously, our pipeline will not be triggered. It also works fine.

But, if we create a PR to the main branch without the [skip ci] in the context when create the PR:

The result is only have the PR trigger for the main branch.

The CI for main branch after PR complete are not triggered：

If we do not add the [skip ci] when we submit from develop branch, the CI for main branch will be triggered after PR completed.

Then I create a similar sample with Azure devops Git repo. I got the different result.

Regardless of whether we include [skip ci] in the PR context, the CI build of the Main branch will be triggered after the PR is completed. This is the expected result, which is obviously different from the result of the github repo

So, we are not sure if this is an issue or default behaver. I have submit a new ticket about it:

https://developercommunity.visualstudio.com/t/Azure-DevOps-Pipeline-not-triggered-for-/1400393

Answer 2

My guess is that the merge commit generates a comment listing all the commit messages for all the included commits. Hence, the commit message of your merge then contains a [skip-ci].

I'm guessing the ideal way to handle this is to either edit the commit message prior to merge or to make sure your skip-ci marker is in the description part of the original commit messages.

This is the first.line of the commit
[skip-ci] < on the second line

That way it gets omitted in the merge commit message.

Answer 3

I have now circumvented this issue by removing the [skip ci] commit and using some exclude path filters on the the CI triggers.

This introduces some other minor issues, but for now this works for us. Obviously this isn't a real solution, so I won't mark anything as an answer for now.