为了给出一些背景信息,我将从我试图实现的目标开始。
我有一个从VSTS服务挂钩接收数据的Web服务。服务挂钩在创建或更新PR时以及“拉出请求合并尝试”时发布数据。
我的网络服务的目的是检查PR的源分支是否与目标分支保持同步。
一切正常,当创建PR时以及源分支发生变化时(这相当于PR创建和PR分别更新)。
但是,如果在PR等待完成时更新目标分支,我希望将我的服务发布到,这可以将PR状态设置为失败,因为源分支不再是最新的。
如果我更新目标分支,目前我可以完成PR,即使我的服务已经再次发布,也会说“不,你不能完成这个”。我可以手动强制它再次发布到服务,但在PR上使用“重新启动合并”,但这并不理想。重新启动合并的过程必须激活“Pull Request Merge Attempted”事件。
那么我想知道的是,如果有一种方法可以在Target分支更新时自动重试合并吗?
对此有任何帮助(或者如果您有关于完成此操作的一些提示,请检查源是否与目标保持同步)将非常感谢!
由于
答案 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。