Azure DevOps队列构建仅在任务取消/失败后运行的原因排查

核心原因：代理资源被占用 #

你遇到的情况大概率是当前运行PowerShell脚本的流水线任务占用了代理池中的唯一代理，导致新触发的构建因无可用代理而排队，直到当前任务被取消/超时释放代理后，新构建才能获取资源启动。

具体验证点&解决办法 #

1. 检查代理池配置 #

• 查看Azure DevOps代理池（项目设置→代理池）中的代理数量：如果只有1个代理，当前脚本任务会一直占着这个代理（循环sleep+检查状态），新构建只能排队等待。
• 解决：要么增加代理池中的代理数量，要么调整脚本逻辑，避免长时间占用代理。

2. 修改脚本逻辑，释放代理资源 #

不要让当前任务一直挂着循环检查，改成异步监控方式：

• 触发构建后，记录下返回的buildOutput.id，然后结束当前任务。
• 用另一个独立的流水线（通过定时触发器，比如每1分钟运行一次）来根据构建ID查询状态，或者利用Azure DevOps的构建完成事件（项目设置→服务挂钩中配置）接收状态通知，无需持续占用代理。

修改后的触发脚本可简化为：

$Uri = 'https://dev.azure.com/{MY ORG}/{MY PROJECT}/_apis/build/builds?api-version=5.0'
$buildOutput = Invoke-RestMethod -Uri $Uri -ContentType "application/json" -Headers $headers -Method POST -Body ($buildBody | ConvertTo-Json)
# 输出构建ID，供后续监控使用
Write-Host "Triggered build with ID: $($buildOutput.id)"

3. 调整流水线并发限制 #

• 检查项目级并行作业限制：项目设置→流水线→并行作业，确认是否限制了同时运行的作业数量。
• 检查流水线级并发设置：编辑流水线→触发器→并发，开启“允许同时运行多个流水线实例”，避免同一流水线的任务互相阻塞。

4. 验证构建定义的代理需求 #

确认你触发的目标构建定义是否指定了特定的代理队列/需求，而该代理恰好被当前脚本任务占用。如果是，尝试调整代理需求，或增加对应队列的代理数量。

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