We have setup a build policy as part of our CI pipeline into master branch. The policy ensures that the PR changes + master head builds successfully before squash merging the PR changes into master.
We came across a situation today where two separate change lists (which have no merge conflicts with master and among themselves) made it into master branch, but when the second change list completed, the rolling master build failed.
Upon analyzing, we noticed that the second PR already had succeeded the build policy before the first PR was completed. Hence the second PR never built with now new head and current changes prior to merging to master which would have caught the issue.
Hence the question, how to invalidate all builds on open PRs when another commit goes into master.
Navigate to the
Branches
section, click the ellipses next to master and selectBranch policies
.Then add a
Build Validation
policy. Link to a existing build definition and then set the following fields:This way PRs targeting master will always require a new build whenever either the feature branch is update or master is updated, ie a different PR was accepted into master.
My guess, based on your description, is you have
Build expiration
set to something other than Immediately, thus when PR 1 got merged to master, PR 2's build was not correctly expired, so VSTS didn't require the PR 2 to be rebuilt and instead allowed PR 2 to be merged.