Azure DevOps如何通过REST API关联工作项以完成Pull Request

• PR完成校验逻辑判断“是否关联工作项”的依据，是直接读取PR实体自身存储的关联工作项清单，不会反向遍历全量工作项的关联记录做匹配。仅在工作项侧添加指向PR的关联关系，不会更新PR本身的关联字段，自然会触发校验拦截。
• 手工构造的PR关联链接格式不匹配系统识别规则时，即使工作项接口返回更新成功，也会出现PR页面不展示关联关系、双向联动失效的问题。
• 跳过前置关联步骤直接调用PR完成接口，会被内置的工作项关联策略强制拦截，报错提示要求关联工作项。

创建PR阶段完成关联（推荐，无额外校验遗漏） #

• 调用创建PR的POST接口时，只要保证PR源分支的最新提交信息包含固定格式的工作项ID（例如 修复登录鉴权问题 #12345，其中12345为目标工作项ID），Azure DevOps会自动在PR创建完成时，将对应工作项同步写入PR的关联列表，同时实现工作项侧和PR侧的双向关联展示，无需额外调用关联接口。
• 无需在PR创建的请求体中手动拼接复杂的关联参数，依赖commit message的自动关联机制即可满足后续完成校验的要求。

已创建PR的补关联操作 #

• 优先调用PR实体侧的关联工作项接口完成绑定，而非仅修改工作项的关联记录：
  • 请求方法：PUT
  • 接口地址：https://dev.azure.com/{组织名}/{项目名}/_apis/git/repositories/{仓库ID}/pullRequests/{PRID}/workitems?api-version=5.1
  • 请求体格式：直接传入目标工作项的完整REST接口地址即可，示例：

    "https://dev.azure.com/{组织名}/{项目名}/_apis/wit/workItems/{工作项ID}"
    

  • 接口调用成功后，PR的关联列表会直接写入对应工作项，PR页面和工作项页面会同步展示双向关联关系，可直接通过完成校验。
• 修正原有工作项关联逻辑的格式偏差：
  • 原有构造的vstfs:///Git/PullRequestId/格式链接中，项目、仓库字段需要填写项目/仓库的名称字符串或真实GUID，不能填写系统内部的数字项目ID，否则系统无法识别关联对象。
  • 调用工作项关联接口时，无需手动给关联添加name: "Pull Request"的自定义属性，系统会根据ArtifactLink的类型自动识别关联方向。

关联完成后执行PR收尾操作 #

• 直接使用现有PATCH请求格式将PR状态设为completed即可，注意替换的$CommitId必须为PR源分支当前的最新commit ID，否则会触发提交版本不匹配的报错。
• 发起完成请求前，可通过PR详情接口拉取PR元数据，确认返回结果中已存在对应工作项的关联条目，再触发完成操作即可绕开校验拦截。

• 不要仅依赖修改工作项关联的方式满足PR完成校验，该操作不会更新PR自身的关联字段，无法通过系统校验逻辑。
• 不要认为接口返回200就代表关联生效，参数格式错位、对象ID填错时，关联记录会存在但无法被系统识别，自然不会实现双向展示。
• 不要在未完成关联校验的情况下直接修改PR状态为completed，会被内置策略强制拦截。

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