我有一个有两个分支的仓库：
众所周知，develop分支中的代码可以作为“ alpha”版本发布，而master中的代码则可以投入生产。
当前，develop分支机构的策略要求必须成功完成CI构建才能使PR合并。该版本将创建带有预发布标签（alpha-####）的NuGet软件包工件。
发布管道负责获取这些软件包并将其发布到内部NuGet提要中。
我要实现的目标是在PR完成后自动触发触发发布管道，每当CI构建成功时不。
我希望“拉动请求触发器”能够做到这一点，但令我惊讶的是，触发器不会承认PR的状态，并且在CI构建完成后立即启动发布管道。
这意味着如果PR由于某种原因被拒绝，NuGet可能仍会部署到我的供稿中！
我在这里做错了什么？拉取请求触发器为何与连续部署触发器没有什么不同？那是什么目的？ ：/
答案 0 :(得分：2)
不确定一年多后是否有人仍在寻找解决方案，但我写了一个 Azure Function 应用程序来接收来自 DevOps 的拉取请求关闭 webhooks 并将这些事件转换为新版本。
你可以在我的 github 上找到它：https://github.com/GravlLift/OnPullRequest
随意分叉它以满足您的个人需求。
答案 1 :(得分：1)
连续部署触发器意味着，如果您在发布管道中指定了某些类型的工件，则可以启用连续部署。这指示Azure Pipeline在检测到可用的新工件时自动创建新版本。
Pull Request触发意味着，一旦配置了Pull Request版本，只要对受保护分支提出了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，建议您创建一个新的构建管道并为其启用持续集成。然后将此构建管道设置为Release管道工件。 因为PR完成后，它将创建对目标分支的新提交，并且此新提交将触发构建管道，并且构建管道将触发发布管道以按预期部署Nuget。