Azure DevOps：如何在拉取请求完成后触发发布？答案

【问题标题】：Azure DevOps: how to trigger a release upon pull request being completed?Azure DevOps：如何在拉取请求完成后触发发布？
【发布时间】：2020-01-25 02:54:23
【问题描述】：

我有一个有两个分支的仓库：

develop（repo 的默认分支）
主人

develop 分支中的代码已知可作为“alpha”版本发布，而 master 中的代码已知可用于生产。

目前，开发分支的政策要求必须成功完成 CI 构建才能合并 PR。该构建将创建带有预发布标记 (alpha-####) 的 NuGet 包工件。

发布管道负责获取这些包并将它们发布到内部 NuGet 源。

我想要实现的是在 PR 完成时自动触发发布管道，不是只要 CI 构建成功。

我希望“拉取请求触发器”能够做到这一点，但令我惊讶的是，触发器不会确认 PR 的状态，并且会在 CI 构建完成后立即启动发布管道。

这意味着，如果 PR 因任何原因被拒绝，NuGet 仍可能部署到我的提要中！

我在这里做错了什么？为什么拉取请求触发器与持续部署触发器的工作方式没有任何不同？那它的目的是什么？：/

【问题讨论】：

让合并触发构建。让构建触发发布。
@DanielMann 合并是指 PR？因为我已经试过了。 PR 将导致构建启动，但我需要在 PR 已完成的条件下进行发布。
@DanielMann 所以今天早上我已经恢复了理智，现在我明白你的意思是在开发分支上有一个带有 CI 触发器的构建定义。当然，那会奏效。我只是讨厌在发布之前必须等待另一个构建（以及分支策略构建）。

标签： azure-devops continuous-integration nuget continuous-delivery

【解决方案1】：

持续部署触发器意味着，如果您在发布管道中指定某些类型的工件，则可以启用持续部署。这会指示 Azure Pipeline 在检测到新工件可用时自动创建新版本。

Pull request trigger 意味着，一旦配置了 pull request 发布，只要对受保护的分支提出拉取请求，就会自动触发发布，部署到指定的环境。

所以这两个触发器是不同的，更详细的信息可以参考这里。 https://docs.microsoft.com/en-us/azure/devops/pipelines/release/deploy-pull-request-builds?view=azure-devops

https://docs.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=azure-devops

如果您在 PR 完成后仍想部署 Nuget，我建议您创建一个新的构建管道并为其启用持续集成。然后将此构建管道设置为发布管道 Artifact。因为当一个 PR 完成后，它会创建一个新的提交到目标分支，这个新的提交会触发构建管道，构建管道会触发发布管道，按照您的预期部署 Nuget。

【讨论】：

谢谢。使用启用了 CI 的第二个构建是我辞职要做的事情。我只是希望有更好的方法。我发现只有策略一个就可以了时，必须同时完成分支策略构建和合并构建是很愚蠢的。我将尝试在发布管道上使用分支过滤器，这样我就可以摆脱对 CI 和分支策略都只有一个构建定义的情况。希望它会奏效。 :s

【解决方案2】：

不确定是否有人在事后一年多仍在寻找解决方案，但我写了一个 Azure Function 应用程序来接收来自 DevOps 的拉取请求关闭 webhook 并将这些事件转换为新版本。

你可以在我的 github 上找到它：https://github.com/GravlLift/OnPullRequest

随意分叉它以满足您的个人需求。

【讨论】：