我们最近对PR上的构建验证门进行了更改，以便在当前PR完成之前，如果另一个提交使其成为主分支，则构建将“立即”到期。请参阅here。
尽管此更改可确保主数据始终准确/可构建/健康，但这似乎对开发人员的工作效率几乎没有负面影响：
我想自动化（1）和（2）。有没有办法我可以设置VSTS构建验证，这样对于所有打开的PR，在构建到期时，它会自动使用master重新/重新合并源分支，然后重新排队构建？
答案 0 :(得分：0)
我在组织中遇到了这个问题。当有多个PR试图进入同一时间时，设置Build expiration to Immediately会变得过于繁琐。
AFAIK - 每当master更新时，都无法自动触发定位master的所有PR的重建。如果您想要挂钩VSTS事件并自己编写代码，我确定基础知识存在。但是上次我看起来并没有开箱即用。
我的组织所做的是接受妥协。我们配置PR，以便构建在1小时后过期。这样，当多个PR同时尝试合并时，没有争用。但是，这有你在原始问题VSTS : Invalidating builds on existing PRs when another commit makes it into master branch中描述的缺点，因为两个不兼容的PR快速合并，目标分支（即master）可能会被破坏。 / p>
我们最终只是接受了这种限制
我们在所有分支（功能，master等）上都有一个触发器，每当添加新提交时，我们会自动触发新的构建。这样，如果PR设法中断master，我们会在几分钟内收到有关它的电子邮件。
如果主分支（即master）被破坏，则所有新PR将开始失败的构建。因此，没有新的PR可以合并。这通常会引起所有人的关注，因此问题很快就浮出水面 - 整个团队开始努力修复master。
在部署master之前，我们运行完整的VSTS构建，包括单元测试。这样，如果主分支被破坏（由两个不兼容的PR或任何其他原因），我们确保停止部署。
所以，不幸的是，我们无法保证 master始终处于良好状态的100％。达到100％只会对我们的工作流程和工作效率产生太大的负面影响。因此，我们接受了我们的限制，并确保尽快通知我们，并在分支中断时处理这种情况。