如何在Azure DevOps Release流水线触发Build流水线并等待完成

不需要依赖第三方扩展，以下两种方案均经过生产环境长期验证，可稳定实现你需要的流程逻辑。

前置权限配置 #

所有触发方案生效的核心前提：给Release运行使用的服务账号（对应项目的Build Service账号）授予目标构建流水线的「队列构建」「查看构建」权限，设置为允许，这也是多数第三方扩展配置失效的核心原因，和扩展本身功能无关。

方案1：原生REST API实现（最稳定，零依赖） #

该方案完全基于Azure DevOps原生开放接口实现，不受平台版本更新、扩展下线/兼容问题影响，稳定性最高。

1. Artifact生成环节直接使用Release原生的Artifact关联能力，绑定你初始的产出包流水线，触发规则设置为「新Artifact生成时自动创建Release」，即可满足新包生成触发流程的要求。
2. Stage 1阶段按顺序添加两个PowerShell任务（支持Windows/Linux代理，也可替换为等效的Bash/Azure CLI任务），第一个任务对应触发第一条Build流水线，第二个对应触发第二条Build流水线。
   • 任务配置时勾选「允许脚本访问OAuth令牌」，不需要手动配置个人访问令牌。
   • 第一个任务的核心逻辑参考如下代码：

# 触发目标构建
$requestUri = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/builds?api-version=7.1"
$requestBody = @{
    definition = @{ id = <替换为第一条目标Build流水线的定义ID> }
} | ConvertTo-Json -Depth 10

$triggerResult = Invoke-RestMethod -Uri $requestUri -Method Post -Body $requestBody -ContentType "application/json" -Headers @{Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"}
$runningBuildId = $triggerResult.id

# 轮询等待构建执行完成
do {
    Start-Sleep -Seconds 20
    $buildStatus = Invoke-RestMethod -Uri "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/builds/$runningBuildId?api-version=7.1" -Headers @{Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"}
} while ($buildStatus.status -ne "completed")

# 校验构建结果，失败则直接终止流程
if ($buildStatus.result -ne "succeeded") {
    Write-Error "触发的第一条构建执行失败，最终状态：$($buildStatus.result)"
    exit 1
}

- Release Pipeline默认按任务顺序执行，上一个任务失败会直接终止当前Stage，因此第二个任务天然会在第一个任务（即第一条Build流水线）执行成功后才启动，不需要额外配置执行条件。第二个任务的代码和上述逻辑一致，只需要替换为第二条目标Build流水线的ID即可。

方案2：官方内置任务实现（零代码） #

如果不想编写自定义脚本，直接使用微软官方维护的内置任务即可，不要使用第三方个人开发者发布的同类扩展：

• 在任务市场筛选发布者为Microsoft的Build Azure DevOps Pipeline任务，该任务为官方原生维护，不存在兼容失效问题。
• Stage 1内按顺序添加两个该任务，分别选中需要触发的两条目标Build流水线，两个任务都开启「等待触发的构建完成」「构建失败时标记任务为失败」配置项，保存后即可实现要求的串行执行、失败即终止的逻辑。

第三方扩展失效的常见原因包括：未适配Azure DevOps迭代后的API版本、任务内权限配置逻辑缺陷、轮询间隔设置不合理导致的状态误判，上述两个方案均规避了这类问题。

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