Azure DevOps Pipeline 存于develop分支时无法被adf_publish分支变更触发

你遇到的是Azure DevOps YAML管道CI触发器的默认生效规则导致的常见误区：

对于YAML管道，当推送到某分支时，CI触发器的配置是从被推送的分支上的对应YAML文件中读取的，而非从你创建管道时使用的源分支读取。

这直接解释了你观测到的两个现象：

• YAML存放在develop分支时，推送到adf_publish后，系统会先去adf_publish分支查找这份YAML文件，找不到就直接静默终止触发流程，哪怕develop分支的YAML里写了include adf_publish也不生效。
• YAML放到adf_publish分支时，推送到该分支后系统能直接找到YAML、读取到触发配置，自然能正常触发。

根据你的需求（YAML固定存放在develop分支，仅通过adf_publish分支变更触发运行），推荐以下两种方案：

方案1：使用资源仓库触发器（推荐） #

这种方式不需要把YAML同步到adf_publish分支，完全用develop分支的YAML控制触发逻辑，配置如下：

• 注释掉原来的顶层trigger配置，避免默认触发逻辑冲突
• 在YAML中添加resources块，显式声明同仓库的监听规则，固定使用develop分支的YAML执行

完整配置示例：

# 注释原有顶层触发配置
# trigger:
#   branches:
#     include:
#       - adf_publish

resources:
  repositories:
    - repository: self  # 指代当前代码仓库
      type: git
      ref: develop  # 固定拉取develop分支的YAML及代码，也可按需调整ref规则
      trigger:
        branches:
          include:
            - adf_publish  # 仅监听adf_publish分支的变更

方案2：双分支同步YAML配置 #

如果你一定要保留顶层trigger的写法，就必须在adf_publish分支上也保留一份和develop分支完全一致的YAML文件：

• 每次修改develop分支的YAML后，必须同步提交一份到adf_publish分支
• 这种方式维护成本高，容易出现分支间配置不一致的问题，仅适合临时场景使用

完成YAML配置后，还要检查两处设置避免触发被覆盖：

• 打开管道编辑页，进入「更多选项」->「触发器」->「持续集成」标签
• 确认未勾选「覆盖YAML触发器」选项，避免UI侧的手动配置覆盖YAML中的触发规则
• 确认管道的构建服务身份对仓库拥有读取权限，避免权限问题导致触发后运行失败

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