Azure DevOps Pull-Request: Additional commits in a existing Pull-Request trigger rebuilds, ignoring the Path filter in the Build Policy

Question

I've created a build policy to run a CI pipeline if a part of the codebase has been changed. I want to excluded files from retriggering a build.

When creating a pull-request with changes in the README.md file, the build is not triggered (as expected).

When creating a pull-request with changes in other files, the build triggered (as expected)

When creating a pull-request with a change in another file, the build is triggered, but when I commit a change to the README.md file, it fails the current build and starts a new build. (not expected, I expect the path filter to prevent a rebuild because the file should be ignored for this build)

It seems the build policy path filter only works when creating the pull request.

Is there a way to commit files to an existing pull-request without triggering a rebuild?

Answer 1

I could not solve the problem with rebuilding on a new commit.

However, I could solve our particular problem. There's a step in our pipeline which generates files and commits them, which trigger the rebuild. I've added a step which checks if the files are already added and skips committing a generated again.

To check if the file already exists in the pull request, I use the following command:

git diff origin/master -- {filename} --exit-code --shortstat

Answer 2

According to your description, I could reproduce this situation.

Here is a ticket about the explanation about this situation.

Is there a way to commit files to an existing pull-request without triggering a rebuild?

You could refer to the workaround in the ticket above.

For another workaround: you could try to set the “Trigger” as ‘Manual’ in "Build validation".

In this case, you can manually queue build in Pull Request.

When a new commit is submitted to the source branch, the current build can continue to run without directly failing.

Hope this helps.