ADO构建流水线关联工作项异常及程序化获取PR ID的问询

问题1：为何部分构建显示PR关联的正确工作项，部分却显示所有变更作为关联项？ #

这是因为ADO构建关联工作项的逻辑会根据构建触发方式、合并策略的不同而变化：

• 如果构建是由PR squash合并触发：ADO会直接关联PR中指定的工作项，不会遍历历史变更——因为squash合并会把PR的所有提交压缩成一个新提交，这个提交仅关联PR绑定的工作项。
• 如果构建是由普通保留历史合并或直接分支推送触发：ADO会遍历构建范围内的所有变更提交，把每个提交关联的工作项都拉进来，就会出现“所有变更及工作项”的情况。
• 另外检查流水线触发规则：如果部分构建是手动触发、或者由非PR合并的分支推送触发比如直接推develop，也会导致关联所有历史变更的工作项，而非PR绑定的特定项。

问题2：如何从构建中程序化获取PR ID？ #

有两种可靠方式：

方式1：通过Build REST API解析触发信息 #

调用ADO Build API获取构建详情，解析响应中的triggerInfo字段，PR相关的ID会在这里：

GET https://dev.azure.com/{组织名}/{项目名}/_apis/build/builds/{buildId}?api-version=7.1-preview.7

响应示例中triggerInfo的PR相关字段：

"triggerInfo": {
  "pullRequestId": "456",
  "pr.number": "456",
  "pr.targetBranch": "refs/heads/develop"
}

直接提取pullRequestId或pr.number即可得到PR ID。

方式2：在流水线中直接获取内置变量 #

如果是PR触发的流水线包括PR合并后的触发，ADO会自动注入内置变量System.PullRequest.PullRequestId，可以在流水线脚本中直接读取该变量，比如PowerShell：

$prId = $env:SYSTEM_PULLREQUEST_PULLREQUESTID

可以把这个ID写入构建的自定义属性或变量组，方便后续脚本调用。

问题3：其他可行的解决思路？ #

• 统一合并策略：强制要求合并到develop分支时使用squash合并，这样每次合并只会生成一个关联PR工作项的提交，构建只会关联这些指定工作项，不会拉取历史变更的项。
• 提前获取PR工作项并存储：在PR验证流水线合并到develop之前的流水线中，调用PR API获取关联的工作项，将结果存储到构建的附件、自定义变量或Azure存储中，后续合并后的构建直接读取这个预存数据，无需再从构建关联项中筛选。
• 筛选构建关联的工作项：如果无法避免获取到所有变更的工作项，可以在脚本中过滤：只保留与本次合并提交相关的工作项通过构建的lastChangeset字段定位合并提交，再关联对应的工作项，忽略历史变更的项。
• 使用变更集关联筛选：通过Build API获取构建的变更集列表，只处理最新的合并变更集关联的工作项，跳过之前的历史变更集。

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