VSTS:当另一个提交进入主分支时，Invalidating构建在现有的PR上 [英] VSTS : Invalidating builds on existing PRs when another commit makes it into master branch
问题描述
我们已将构建策略设置为进入主分支的CI管道的一部分.该政策可确保在将PR更改合并到master中之前，成功完成PR change + master head的构建.
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.
我们今天遇到了这样一种情况:两个单独的变更列表(与master以及彼此之间没有合并冲突)将其放入master分支，但是当第二个变更列表完成时，滚动的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.
通过分析，我们注意到第二个PR在第一个PR完成之前已经成功完成了构建策略.因此，在合并到母版之前，第二个PR从来没有使用现在的新标题和当前更改来构建，而这会引起问题.
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.
这样一个问题，当另一个提交进入主控状态时，如何使所有在开放式PR上的构建无效.
Hence the question, how to invalidate all builds on open PRs when another commit goes into master.
推荐答案
导航到Branches部分，单击master旁边的省略号，然后选择Branch policies.
Navigate to the Branches section, click the ellipses next to master and select Branch policies.
然后添加一个Build Validation策略.链接到现有的构建定义，然后设置以下字段:
Then add a Build Validation policy. Link to a existing build definition and then set the following fields:
- 触发:自动
- 政策要求:必需
- 构建到期:立即
- Trigger: Automatic
- Policy Requirement: Required
- Build expiration: Immediately
这样，只要功能分支更新或 master进行更新(即，将不同的PR接受到master中)，面向master的PR始终将需要一个新的构建.
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.
根据您的描述，我的猜测是您已将Build expiration设置为立即以外的其他内容，因此，当PR 1合并到主服务器时，PR 2的构建未正确过期，因此VSTS不需要重建PR 2，而是允许合并PR 2.
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.
这篇关于VSTS:当另一个提交进入主分支时，Invalidating构建在现有的PR上的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
