Question

为了给出一些背景信息，我将从我试图实现的目标开始。

我有一个从VSTS服务挂钩接收数据的Web服务。服务挂钩在创建或更新PR时以及“拉出请求合并尝试”时发布数据。

我的网络服务的目的是检查PR的源分支是否与目标分支保持同步。

一切正常，当创建PR时以及源分支发生变化时（这相当于PR创建和PR分别更新）。

但是，如果在PR等待完成时更新目标分支，我希望将我的服务发布到，这可以将PR状态设置为失败，因为源分支不再是最新的。

如果我更新目标分支，目前我可以完成PR，即使我的服务已经再次发布，也会说“不，你不能完成这个”。我可以手动强制它再次发布到服务，但在PR上使用“重新启动合并”，但这并不理想。重新启动合并的过程必须激活“Pull Request Merge Attempted”事件。

那么我想知道的是，如果有一种方法可以在Target分支更新时自动重试合并吗？

对此有任何帮助（或者如果您有关于完成此操作的一些提示，请检查源是否与目标保持同步）将非常感谢！

由于

Answer 1

目前，在将新更改推送到目标分支后，PR不会自动更新，除非您手动单击重新启动合并PR（因为还没有这样的REST API来重新启动PR的合并）。 / p>

在您发现源分支与目标分支（目标分支更新）不是最新后，解决方法是放弃并反应PR ，然后您会发现更新了被动PR。 / p>

要放弃并反应PR，您可以参考REST API：

放弃PR

PATCH https://{account}.visualstudio.com/DefaultCollection/{project}/_apis/git/repositories/{repoID}/pullRequests/{PullRequestID}?api-version=3.0

应用/ JSON

{
  "status": "abandoned"
}

反应性PR

PATCH https://{account}.visualstudio.com/DefaultCollection/{project}/_apis/git/repositories/{repoID}/pullRequests/{PullRequestID}?api-version=3.0

应用/ JSON

{
  "status": "active"
}

Answer 2

可以通过API进行“重新启动合并”。

如果您查看“重新启动合并”按钮的功能（通过“开发工具”的“网络”选项卡），它将在主体的拉取请求（https://docs.microsoft.com/en-us/rest/api/azure/devops/git/pull%20requests/update?view=azure-devops-rest-5.1）上发送PATCH请求：

{"mergeStatus":1}

因此，作为解决方法，您需要做的是一个自定义任务，该任务使用系统访问令牌遍历正在构建的存储库中的所有请求请求，并对所有请求发出PATCH请求。

这很不幸，但并不是很难，如果您愿意用NODE编写它，那么就有NPM包，其中包含Azure DevOps自定义任务SDK和Azure DevOps REST API。