当在VSTS中更新目标分支时,是否可以获得PR以重新启动合并?

时间:2018-03-01 21:28:06

标签: git azure-devops

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

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

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

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

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

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

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

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

由于

PR Top right menu

2 个答案:

答案 0 :(得分: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"
    }
    

答案 1 :(得分:1)

可以通过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。