![\"New](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/6\/2019\/05\/branch-policies.png\")
<\/a><\/p>\n“Buddy Build” Policy<\/h3>\n
The first of the new build policy options is what we sometimes call a “buddy build” policy – that idea being that you’re having someone else build your changes to avoid the “it worked on my box” problem. \u00a0In this case, the “buddy” is the build machine, and like the existing build policy, each time new change are added to the source branch of the PR, those changes are automatically detected and built.<\/p>\n
The big difference with this policy option is that when the target branch is updated, a new build is not required. \u00a0In the policy config UI, we expose this setting under the options for what to do when the target branch is updated\u00a0as\u00a0Don’t require a new build<\/strong>.<\/p>\n So, in the case above where you’re about to merge your PR, and someone else merges their changes, you won’t be forced to rebuild. \u00a0Instead, you’ll see an option to re-evaluate the merge:<\/p>\n Re-evaluating the merge will create a new merge commit and check for conflicts. \u00a0Assuming there are no conflicts, you’ll see a message about the target branch being updated with an option to rebuild. \u00a0With the buddy build policy, all you need is one good build to get approval, so the rebuild would be optional in this case.<\/p>\n The second new\u00a0option for handling builds when there are changes to the target branch enables teams to strike a balance between strict builds and the more relaxed buddy build.\u00a0 The option to Require a new build if older than n hours<\/strong> works pretty much how it sounds.\u00a0 Like the buddy build policy, a change to the target branch doesn’t immediately invalidate the current build.\u00a0 Instead, it sets an expiration time for the build based on the configuration – if the option is configured for one hour, a change to the target branch will cause any PR build to expire one hour from the time it originally completed (not one hour from the time the branch was updated).<\/p>\n In the case where a build is successful and the target hasn’t changed, the build will be good indefinitely.\u00a0 If the build is older than the expiration window and then the target is updated, the build will immediately be invalid and a rebuild will be required.<\/p>\n<\/a><\/p>\n<\/a><\/p>\nBuild Expiration<\/h3>\n
<\/a><\/p>\n