VSTS：自动 rebase/merge 并在构建过期时重新排队构建验证门

VSTS : automatically rebase/merge and requeue build validation gate in case of build expiration

我们最近对 PR 上的构建验证门进行了更改，如果另一个提交在当前 PR 完成之前进入 master 分支，构建就会过期 "immediately"。参见 。

即使此更改确保主控始终是 accurate/buildable/healthy，但这似乎对开发人员的生产力几乎没有负面影响：

  1. 团队成员必须持续关注他们的 PR 以重新排队构建验证。
  2. 他们不仅必须手动重新排队构建，而且在这样做之前，他们必须在重新排队之前手动重新设置他们的分支。
  3. 随着我们向更多 smaller/shippable 签到 master，没有。这种情况发生的次数预计会增加。

我想自动化 (1) 和 (2)。有没有一种方法可以设置 VSTS 构建验证，以便对于所有打开的 PR，在构建到期时，它会自动 rebases/remerges 带有 master 的源分支，然后重新排队构建？

我在我的组织中 运行 遇到过这个确切的问题。当有多个 PR 都试图同时进入时，设置 变得过于繁琐。

AFAIK - 每当 master 更新时，无法自动触发所有针对 master 的 PR 的重建。如果您想连接到 VSTS 事件并自己编写代码，我相信基础知识已经具备。但是我上次看的时候什么都没有out-of-box

我的组织所做的是接受妥协。我们配置 PR，使构建在 1 小时后过期。这样当多个 PR 试图同时合并时就没有争用。但是，这有您在原始问题 中描述的缺点，目标分支（即 master）可能由于两个不兼容的 PR 的快速合并而被破坏。

我们最终接受了这个限制

  • 我们在所有分支（功能、master 等）上都有一个触发器，每当添加新提交时，我们都会自动触发一个新构建。这样，如果 PR 成功中断 master，我们会在几分钟内收到一封有关它的电子邮件。

  • 如果主分支（即 master）被破坏，所有新的 PR 将开始构建失败。因此，无法合并新的 PR。这通常会引起 每个人 的注意，因此问题很快就会浮出水面——整个团队开始着手解决 master。

  • 在我们部署 master 之前，我们 运行 一个完整的 VSTS 构建，包括单元测试。这样，如果主分支被破坏（由两个不兼容的 PR 或任何其他原因），我们确保我们停止部署。

因此，很遗憾，我们无法保证 master 始终 100% 处于良好状态。达到 100% 只会对我们的工作流程和生产力产生太多负面影响。所以我们接受我们的局限性并确保我们尽快得到通知并且可以在分支中断时处理这种情况。