2
votes

In our development, we use a master branch and a release branch. The release branch is protected, and only pull-requests can change the release branch. We have an application that fetches a build artifact from a library pipeline.

I used to have two CI pipelines, one that triggers on changes on master, and one that triggers on PR to release. This works fine, but these two pipelines are almost identical, except that one fetches the library artifact from a master pipeline, and the other from the release pipeline, to compile the application.

To make this more maintainable, I wanted to merge these pipelines and have triggers like this:

# CI triggers
trigger:
  batch: true # To reduce the number of runs to start. Will batch all commits that happen during an active run
  branches:
    include:
    - master

# PR triggers
pr:
  branches:
    include:
    - master
    - release

The triggers and the mechanisms to fetch the correct artifact work fine.

When the compilation using the release artifact fails, the PR on git correctly shows this. However, when a pipeline run triggered by the batchedCI on master succeeds, the PR shows that the run is succesfull (which is not true when using the release artifacts).

How can I use this single pipeline, and have the git PR only look at the pipeline runs triggered by that PR, ignoring those triggered by the BatchedCI on master?

1
I'm not sure if I follow you want to have this pipeline run only for PR and not for CI trigger, right?Krzysztof Madej
No, I would like to use the same pipeline for both PR and CI triggers. The problem is that if a PR trigger fails, and a subsequent CI trigger is successful, the PR is considered to be successful because the latest run is successful.The pipeline itself behaves differently depending on if it's a PR or CI trigger, eg. it fetches required library artifacts from different pipelines. Depending on that, the pipeline can succeed or fail.Bart Masschelein
Do you use Azure Repos or Github?Krzysztof Madej
@KrzysztofMadej I'm using Github (Enterprise).Bart Masschelein

1 Answers

1
votes

Sorry it's not able to do this by default.

You have analyzed and mentioned the root cause clearly:

The problem is that if a PR trigger fails, and a subsequent CI trigger is successful, the PR is considered to be successful because the latest run is successful.

As a workaround, you could try to add an additional status check for your PR.

Branch policies are a powerful feature to ensure high quality code in your repo by establishing requirements for all pull requests. External services can use the PR Status API to post detailed status to your PRs. The branch policy for external services brings the ability for those 3rd party services to participate in the PR workflow and establish policy requirements.

For detail info you could refer our official doc here:

If you feel this make things even more complicated, simply keep two pipelines would also be a choice.