Azure DevOps管道资源触发异常：时机与运行引用不符

问题场景 #

在Azure DevOps中，将Pipeline No.1配置为以Pipeline No.2作为带触发规则的资源，预期Pipeline No.1会在Pipeline No.2生成制品后触发，但实际是Pipeline No.2一启动就触发了Pipeline No.1，且引用的是Pipeline No.2上一次运行的ID和制品。配置代码如下：

pool:
  vmImage: ubuntu-latest

resources:
  pipelines:
    - pipeline: No2Pipeline # 上游Pipeline的别名
      source: CI Pipeline
      trigger:
        branches:
          - dev

steps:
- download: No2Pipeline
  artifact: dummy # 获取到的是上一次运行的制品
- script: |
    echo $(resources.pipeline.No2Pipeline.runID) # 输出的是上一次运行的ID

解决方法 #

1. 精准控制上游触发的完成条件 #

修改Pipeline No.1的资源配置，显式指定触发时机为上游Pipeline成功完成特定阶段后（尤其是发布制品的阶段），确保只有当上游真正生成并发布制品后才触发下游。示例配置：

resources:
  pipelines:
    - pipeline: No2Pipeline
      source: CI Pipeline
      trigger:
        branches:
          - dev
        # 指定仅当上游完成发布制品的阶段后触发，替换为你实际的阶段名称
        stages:
          - PublishArtifact

如果上游Pipeline没有分阶段，仅保留branches配置即可，但需确保上游Pipeline的制品发布步骤是在整个Pipeline的最后环节，且只有前面步骤全部成功才会执行。

2. 检查上游Pipeline的制品发布逻辑 #

确认Pipeline No.2的制品发布任务（如publish任务）是在所有核心构建/测试步骤完成后执行，并且该任务所在阶段只有在前面阶段成功时才会运行。如果上游在启动初期就发布了制品，会导致下游提前触发并获取旧数据。

3. 排查额外触发逻辑 #

检查Pipeline No.2中是否存在直接触发Pipeline No.1的逻辑（比如使用az pipelines run命令、Pipeline任务等），这类逻辑会绕过资源触发的完成校验，导致下游提前启动，需移除这类配置。

原理说明 #

Azure DevOps的Pipeline资源触发默认监听上游Pipeline的成功完成事件，只有当上游Pipeline完成并生成对应制品后，才会将当前运行的ID和制品信息传递给下游并触发。出现提前触发的核心原因是上游的事件通知异常，或者存在绕过完成校验的触发逻辑。

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