我完全理解这种卡在基础触发器配置上的挫败感——尤其是当你已经简化测试场景还没进展的时候！咱们一步步来排查这个问题，重点先解决文件夹路径的核心疑点，再覆盖其他常见坑：

1. 优先修正流水线文件夹路径配置 #

你的猜测是对的！当流水线归类在文件夹中时，source字段必须包含完整的文件夹/流水线名称路径，否则Azure DevOps无法定位到目标流水线资源。

比如如果test-a在名为BuildPipelines的文件夹里，正确的配置应该是：

resources:
  pipelines:
    - pipeline: 'test-a'
      source: 'BuildPipelines/test-a'
      trigger: true

这里的source值要完全匹配流水线在Azure DevOps中的层级路径，你可以在test-a流水线的详情页面URL里找到这个路径（格式类似/BuildPipelines/test-a/_build）。

2. 验证流水线资源的权限设置 #

权限问题是触发器失效的高频原因，你需要确认两个关键权限：

• 进入test-b流水线的编辑页面，点击右上角... → Pipeline settings，切换到Permissions标签，找到Pipeline resources部分，确保test-a流水线拥有Use权限（允许触发当前流水线）。
• 检查组织级的构建服务账户（格式为[你的组织名] Build Service ([你的组织名])）是否对test-a流水线有读取权限，否则test-b无法检测到test-a的运行状态。

3. 确认构建流水线的完成状态 #

默认情况下，流水线资源触发器只会响应成功完成的构建运行：

• 打开test-a的某次成功运行详情，确认顶部状态标记是绿色的Success（不是部分成功或失败状态）。
• 如果需要触发非成功状态的构建，可以在触发器配置里显式添加tags或修改状态过滤，但当前先聚焦成功场景。

4. 查看触发器的运行历史与日志 #

通过日志定位具体失败原因：

• 进入test-b流水线页面，点击Triggers标签，查看Pipeline resource triggers下的历史记录，这里会显示是否有触发尝试，以及失败原因（比如找不到资源、权限不足等）。
• 同时可以在test-a的运行详情页面，查看Related标签，确认是否有触发test-b的记录——如果没有，说明触发逻辑根本未被触发。

5. 简化配置排除干扰 #

暂时移除所有可能冲突的配置：

• 完全删除test-b中的trigger:和pr:配置段，只保留流水线资源触发器，避免CI触发器的逻辑干扰。
• 确保test-b的YAML开头没有trigger: none这类会全局禁用触发器的配置。

6. 显式配置分支过滤（可选） #

虽然你需要支持所有分支，但显式配置分支过滤可以排除分支匹配的潜在问题：

resources:
  pipelines:
    - pipeline: 'test-a'
      source: 'BuildPipelines/test-a'
      trigger:
        branches:
          include:
            - '*'

如果以上步骤都无法解决问题，建议去Azure DevOps的Organization Settings → Audit log中搜索test-a和test-b的相关记录，那里会有更详细的触发失败日志，帮助你定位深层问题。

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