Azure DevOps构建管道关联workitem列表不全问题咨询

运行环境：本地部署 Azure DevOps Server 2020 Update 1.1
前置校验：所有代码提交均已正常绑定1个及以上关联工作项，提交与工作项的关联关系配置无异常。
问题现象：首次运行无历史构建记录的构建管道时，页面展示的关联工作项列表数据缺失：系统统计共展示78个关联工作项，手动核对全量提交历史发现实际共有186个工作项与至少1条提交存在关联，合计108个工作项未出现在列表中，缺失工作项无统一特征。
现象参考截图：

Azure DevOps 2020版本的构建关联工作项逻辑完全由后端内置的「关联并解析工作项」步骤实现，核心规则分两种场景：

• 非首次构建：取当前构建的代码版本、和上一次同分支同管道的成功构建的代码版本做对比，只扫描两个版本之间差集内的所有提交，提取这些提交绑定的工作项，去重后展示。
• 首次构建（无任何历史成功构建记录）：不会扫描分支全量提交，默认仅拉取构建触发时刻对应分支下最近1000条提交记录，扫描这些提交绑定的工作项，再经过内置规则过滤后去重展示。

内置过滤规则包括：

• 自动剔除构建服务账号无读取权限的工作项
• 自动剔除已删除、已销毁、跨项目、归档路径下的工作项
• 自动剔除流水线配置中指定排除的工作项类型
• 仅识别通过官方Git客户端、Web端提交入口、正式API绑定的提交-工作项关联关系，非标准写入的关联不会被识别

结合2020 Update 1.1版本的已知特性和版本缺陷，常见原因按概率从高到低排序：

• 触发首次构建的默认扫描上限：首次构建默认仅扫描最近1000条提交，如果分支全量提交数超过1000，更早提交绑定的工作项会直接被排除在扫描范围外，这是该版本最常见的首次构建关联缺失原因。
• 构建检出配置为浅克隆：2020版本管道默认的代码检出步骤开启浅克隆，默认拉取深度不足时，本地工作区拿不到足够的提交历史，后续关联扫描步骤只能基于拉取到的少量提交做匹配，导致结果不全。
• 构建服务账号权限不足：构建运行使用的服务账号如果对部分工作项所在的区域路径、迭代路径没有读取权限，扫描到关联关系后也会因为权限校验不通过，直接过滤掉这部分工作项，不会展示在前端列表。
• 关联关系非标准写入：如果部分提交和工作项的关联是通过第三方插件、旧版SOAP接口、直接修改数据库写入的，没有写入到2020版本默认的tbl_GitCommitWorkItemLink关联表，内置扫描步骤读不到这部分关联关系。
• 版本已知bug：2020 Update 1.1存在已知的关联去重逻辑缺陷，如果同一个工作项同时被cherry-pick的重复提交、跨仓库提交关联，有概率被去重逻辑误判为无效关联过滤掉。
• 工作项状态触发过滤：部分缺失工作项如果被设置为“已关闭（不再跟踪）”“已删除”状态，或者被移动到当前项目外的集合，会被默认过滤规则排除。

所有操作均可在本地部署环境直接完成：

• 开启调试日志重跑构建：编辑管道，添加系统变量system.debug，值设为true，队列构建后下载完整诊断日志，搜索日志中包含ParseWorkItems、AssociateWorkItems关键字的条目，可直接查看扫描的提交总数、每个提交匹配到的工作项ID、每一个被过滤工作项对应的过滤原因。
• 核对实际扫描的提交范围：在构建日志的Checkout步骤中，找到实际拉取到本地的最早提交哈希、拉取到的提交总数，和手动统计的全量提交做对比，先确认是不是扫描范围不足导致的缺失。
• 校验服务账号权限：临时将构建服务账号加入项目管理员组，重跑一次构建，如果缺失的工作项正常展示，即可判定为权限配置问题，再逐次缩小权限范围定位具体缺失的权限点。
• 调用本地API校验关联结果：用构建服务账号的身份调用本地Azure DevOps Server的REST API，接口格式为GET http://{本地Azure DevOps服务地址}/{项目集合}/{项目}/_apis/git/repositories/{仓库ID}/commits?searchCriteria.$top=1000&includeWorkItems=true，对比API返回的工作项列表和构建页面展示的列表，如果API返回的结果本身不全，问题出在后端关联扫描逻辑；如果API返回全量结果但页面展示不全，问题出在前端渲染模块。
• 校验关联表数据：本地部署环境可直接查询配置库的tbl_GitCommitWorkItemLink表，确认缺失的工作项和对应提交的关联关系是否正常写入，排除非标准写入导致的识别失败。

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