We have a git repo in AzureDevop with 300+ contributors and I was wondering if we can reject the commit to master if the build would fail on completing the PR. On absence of this solution, when one PR merge build fails, there's a risk that other branches will pull defected product in or other people merge will also fail.
-
Yes you can do this as [documented here](https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#build-validation) – Liam Oct 26 '20 at 10:58
1 Answers
Yes. this is possible and this feature is called branch policy
The specific option for this is called Build validation
Build validation
Set a policy requiring changes in a pull request to build successfully with the protected branch before the pull request can be completed. Build policies reduce breaks and keep your test results passing. Build policies help even if you're using continuous integration (CI) on your development branches to catch problems early.
If a build validation policy is enabled, a new build is queued when either a new pull request is created, or if changes are pushed to an existing pull request targeting the branch. The build policy then evaluates the results of the build to determine whether the pull request can be completed.
To enable this you need to go to Branches and then select branch which you want to protect:

- 32,704
- 10
- 78
- 107
-
Thank you so much for responding Krzysztof. it's still not clear to me though how this is going to solve me issue. the build on my feature branch is successful but only when I merge the changes to master, the build can fail because for example one of the used functions in another target that is not changed directly by me has changed and merged in another merged PR. will that master branch policy still help me in this case? – Afflatus Oct 26 '20 at 13:49
-
@Afflatus If the changes of other users have been merged into the master branch, you may be prompted for conflicts when you make a merged pr. `Build validation` is independent for each pull request. – Hugh Lin Oct 27 '20 at 09:00
-
@HughLin-MSFT not necessary. the issue occurs when the changed target is not the in the PR. the PR has only a call to a function to that changed target. – Afflatus Oct 27 '20 at 11:06