使用分支策略，我启用了对拉取请求的构建验证。现在，每当我创建拉取请求时，我都可以看到一个构建被触发，并且根据构建的状态，我可以完成/保留拉取请求。一切都很好。
现在考虑 2 个并行拉取请求场景 PR1：正在进行中并通过构建验证获得绿色构建。审稿人可以完成此 PR。
PR2 也在进行中，其中有一些更改可能会使 PR1 更改中的少数测试用例失败。PR2 构建验证构建是绿色的，此 PR2 已批准并完成并合并到 master。
现在，PR1 已获得批准（因为它之前获得了绿色版本）并完成并合并到 master 中。一旦 PR1 更改合并到 master，master 现在是一个损坏的分支。
如何避免这种情况？当 PR 更改实际上合并到 master 中时，我们如何触发门控签入/预提交构建？
当 PR 更改实际上合并到 master 中时，没有门控签入/预提交构建，但您可以轻松避免这些情况。
在构建验证（在分支策略中）中，只需在“构建过期”中标记 - 更新时立即master：
更新分支名称时立即：此选项将拉取请求中的构建策略状态设置为在更新受保护分支时失败。重新排队构建以刷新构建状态。此设置可确保即使受保护的分支发生更改，拉取请求中的更改也会成功构建。此选项最适合具有重要分支且更改量较少的团队。在繁忙的开发分支中工作的团队可能会发现每次更新受保护的分支时等待构建完成会造成干扰。
作为一种解决方法，您可以Approvals and checks为 pipleline1 设置，并通过 rest api 检查 PR2 的状态。如果 PR2 的状态为 not completed，则 pipeline1 不会开始运行，则 PR1 的 Build 验证无法完成，PR1 无法合并，直到 PR2 完成。
在 Pipeline1 中添加一个 Environment，Environment 包含检查：Invoke Rest API 以检查 Pull Request 的状态。
环境：Pipelines -> Environemnts-> Approvals and checks -> Invoke Rest API
有关详细信息，您可以参考这里的案例。