Azure DevOps Pipeline：控制多管道触发逻辑（区分调度与手动触发）

方案1：在Pipeline B的触发配置中添加过滤条件 #

直接修改Pipeline B的YAML，仅允许由调度触发的Pipeline A来触发它：

trigger: none

resources:
  pipelines:
  - pipeline: PipelineAliasA  # 为Pipeline A设置别名
    source: '你的Pipeline A名称'  # 替换为实际的Pipeline A名称
    trigger:
      branches:
        include:
          - main  # 替换为你的目标分支
      conditions:
        - resources.pipeline.PipelineAliasA.reason == 'Schedule'

配置完成后，只有当Pipeline A是Cron调度自动执行完成时，才会触发Pipeline B；手动执行Pipeline A时，不会触发B。

方案2：在Pipeline A内部添加条件触发逻辑 #

如果需要在Pipeline A里控制是否触发B，可以添加一个条件任务，仅当A是调度触发时才启动B：

jobs:
- job: MainJob
  steps:
    # 这里放你Pipeline A的原有任务（构建、测试等）

- job: TriggerB
  condition: eq(variables['Build.Reason'], 'Schedule')  # 仅调度触发时执行
  steps:
  - script: |
      az pipelines run --name "你的Pipeline B名称" --branch main --org $(System.CollectionUri) --project $(System.TeamProject)
    env:
      AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
    displayName: '触发Pipeline B（仅调度场景）'

注意：使用此方案时，需要在Pipeline A的代理作业设置中开启允许脚本访问OAuth令牌，同时确保执行任务的账号有触发Pipeline B的权限。

核心变量说明 #

• Build.Reason：当前Pipeline的触发原因，调度触发时值为Schedule，手动触发时值为Manual。
• resources.pipeline.<Alias>.reason：当Pipeline B被其他Pipeline触发时，该变量存储触发源Pipeline的触发原因。

用以上任一方案，都不需要维护两套Pipeline，通过条件判断即可精准控制触发逻辑，避免管理混乱。

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