Azure DevOps Pipelines PR触发仅运行单阶段、合并后继续执行如何实现

结论 #

完全可以在现有流水线基础上实现，不需要单独新建流水线。新建重复逻辑的流水线只会额外增加维护成本，反而更容易出现配置不一致的问题。

实现方案 #

你只需要结合Azure DevOps流水线的内置触发变量、阶段运行条件、分支策略三个能力就可以完成配置：

1. 新增PR触发器配置

在你的azure-pipelines.yaml头部添加PR触发规则，指定需要监听的目标分支：

pr:
  branches:
    include:
    - main # 替换为你的实际目标分支，比如dev、release/*等

之后进入Azure DevOps项目的分支策略设置，将该流水线添加为PR的必需校验项，确保PR提交后自动触发流水线运行。

2. 为Stage添加运行条件

Azure DevOps内置变量Build.Reason可以区分流水线的触发源：PR触发时值为PullRequest，合并到分支的常规CI触发时值为IndividualCI/BatchedCI。
你只需要给Stage2、Stage3添加运行条件，确保PR触发时不会自动运行这两个阶段：

stages:
- stage: Stage1
  # 原有配置不变，所有触发源下都会运行
  jobs:
  - job: BuildTest
    steps:
    # 原有依赖还原、构建、单元测试、发布制品的步骤不变，注意制品要关联本次提交的哈希值，方便后续复用

- stage: Stage2
  # 仅非PR触发时运行
  condition: ne(variables['Build.Reason'], 'PullRequest')
  dependsOn: Stage1
  # 原有构建推送镜像的配置不变

- stage: Stage3
  condition: ne(variables['Build.Reason'], 'PullRequest')
  dependsOn: Stage2
  # 原有执行bash脚本的配置不变

3. 配置合并后自动复用制品

这里有两种成熟的实现方式，按需选择即可：

• 自动执行方案（推荐）：在流水线的保留策略中配置关联PR的制品最少保留7天，同时给Stage1添加跳过条件：如果当前提交已经存在对应构建制品，就直接跳过Stage1。这样PR合并后触发的CI流水线会自动检测到已有制品，直接运行Stage2、3，不需要重复执行构建测试逻辑。对应的Stage1条件配置如下：

  - stage: Stage1
    condition: or(eq(variables['Build.Reason'], 'PullRequest'), not(artifactExists('YOUR_ARTIFACT_NAME', variables['Build.SourceVersion'])))
  

• 半手动方案：在Stage1和Stage2之间添加一个仅PR触发时生效的手动审批节点，PR合并后由负责人点击审批即可继续运行后续阶段。适合需要人工确认发布的场景。

为什么不推荐单独新建流水线 #

• 两套流水线逻辑高度重复，后续修改构建规则、依赖版本、测试脚本都需要同步修改两处，维护成本翻倍，很容易出现配置不一致的问题
• 跨流水线复用制品需要额外配置权限和拉取逻辑，比在同一条流水线内复用复杂度高很多
• 无法保证两套流水线的构建环境完全一致，容易出现PR校验通过但合并后主分支构建失败的问题

内容的提问来源于stack exchange，提问作者Lud1212