其他流水线更新分支时触发Azure DevOps流水线的方法

问题根因 #

你的判断是对的。Azure DevOps Pipelines 默认做了递归触发防护：所有通过流水线内置系统访问令牌执行的Git推送、合并操作，都会被自动打上特殊标记，默认跳过其他流水线的CI/PR触发规则，这就是你给Sigrid流水线配了master分支触发器也不生效的核心原因，和你在UI上怎么调整覆盖触发配置没关系，这是平台级的默认限制。

方案1：放开流水线提交的触发限制（不推荐） #

如果一定要让级联合并产生的提交自动触发Sigrid流水线，可以在Sigrid流水线的YAML最顶部显式配置，允许来自其他流水线的提交触发自身：

trigger:
  batch: true
  branches:
    include:
      - master
      - release/*
pr:
  branches:
    include:
      - release/*

# 关键配置：放开仓库的流水线触发限制
resources:
  repositories:
    - repository: self
      trigger:
        batch: true

注意：这个方案有明显风险。如果后续Sigrid流水线里新增了往仓库提交代码的步骤，会直接触发自身无限循环运行；如果级联合并流程出现异常反复推送代码，还会导致两条流水线重复触发，排查和管控成本很高。

方案2：级联合并完成后显式调用API触发Sigrid流水线（推荐） #

这个方案完全绕开平台的触发限制，可控性最高，不会出现意外循环触发的问题，实现步骤很简单：

1. 先配置权限：打开Sigrid流水线的安全设置，给项目构建服务账号（就是级联合并流水线运行时使用的<你的项目名> Build Service账号）分配「排队构建」权限。
2. 在级联合并流水线的PowerShell逻辑最后，加一段分支判断：只有确认代码已经成功合并到master分支后，才调用Azure DevOps原生REST API触发Sigrid流水线的master分支运行，示例脚本如下，直接嵌到你现有的级联合并逻辑里就行：

# 替换成你自己环境的参数
$orgName = "你的Azure DevOps组织名"
$projectName = "你的项目名"
$sigridPipelineId = "Sigrid流水线的ID，可从流水线编辑页的URL中获取"

# 直接用流水线内置的System.AccessToken鉴权，不需要额外配置个人访问令牌
$token = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$(System.AccessToken)"))
$headers = @{ Authorization = "Basic $token" }

# 构造请求，指定基于master分支触发，可直接传参指定运行发布任务
$requestBody = @{
    definition = @{ id = $sigridPipelineId }
    sourceBranch = "refs/heads/master"
    parameters = ConvertTo-Json @{
        # 建议在Sigrid流水线新增一个名为RunPublish的流水线变量，默认值为false
        # 触发时传true，直接控制SigridPublish任务运行，不用依赖分支判断，更稳定
        RunPublish = "true"
    }
} | ConvertTo-Json -Depth 10

# 提交构建请求
$apiUrl = "https://dev.azure.com/$orgName/$projectName/_apis/build/builds?api-version=7.1"
Invoke-RestMethod -Uri $apiUrl -Method Post -Body $requestBody -Headers $headers -ContentType "application/json"

3. 可选优化：把Sigrid流水线里SigridPublish任务的触发条件从判断分支，改成判断eq(variables['RunPublish'], 'true')，避免分支同步异常时跑错任务。

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