2026/9/18 13:44:37
FEATURED · 精选文章 
CANN 社区 CI 流水线故障排查实战指南触发失败、静态检查与单元测试常见问题 FAQ 解析【免费下载链接】infrastructure本仓库用于托管CANN社区基础设施团队的公开信息包括不限于会议日程成员信息服务文档和配置等信息项目地址: https://gitcode.com/cann/infrastructureCANN 社区通过 GitCode CI 流水线对每一个 Pull Request 执行编译构建、静态检查、单元测试等质量门禁任何一环失败都会阻塞代码合入。本指南以仓库 docs/ci/ci_faq.md 为骨架系统梳理开发者最常遇到的三大类 CI 故障——流水线触发失败、codecheck 静态检查失败、单元测试覆盖率不达标——并逐一给出现象描述、根因分析与可落地的解决方案。读完本文你将掌握从评论区无反应到覆盖率红线等典型异常的标准处置流程并能结合 CI 流水线配置指导 与 CI 工程检查项概览 理解这些问题背后的触发机制、Job 编排与覆盖率判定逻辑。目录快速检索一、CANN 社区 CI 工程与 FAQ 定位二、流水线触发失败三、静态检查失败四、单元测试失败五、PR 流水线异常排查方法论六、FAQ 之外的求助渠道七、更新日志一、CANN 社区 CI 工程与 FAQ 定位1.1 检查项全景三类质量门禁CANN 社区 CI 工程的检查项分为静态检查、编译构建、测试三大类覆盖代码提交到合入的全过程。依据 docs/ci/ci_guide.md 中的检查项概览主要任务包括静态检查codecheck_{xxx}安全与质量类静态代码检查、antiposion_{xxx}恶意文件全量扫描、SCA_{xxx}开源引用合规性检查、codecheck_PrPR 内容合规性校验如空文件、二进制文件混入、PR 描述完整性、API_CheckAPI 接口兼容性全量校验、StaticCheck_*系列md 文档的拼写、资源存在性、链接有效性、HTML 标签闭合、Markdown 格式规范检查、codecheck_precommit代码格式化与敏感信息筛查。编译构建Compile_{xxx}_X86与Compile_{xxx}_ARM分别在 x86 与 ARM 平台完成源码编译、依赖拉取与可执行文件生成。测试UT_{xxx}单元测试含覆盖率门禁、ST_{xxx}系统集成测试、PreSmoke_{xxx}冒烟测试。评论pre_comment流水线触发后的预评论与last_comment执行完成后的总结评论汇总成功/失败明细、失败日志、编译产物与覆盖率报告链接。FAQ 聚焦的正是其中最常出问题的环节流水线触发对应评论环节与 get-pr 合并、静态检查codecheck与单元测试UT 覆盖率门禁。1.2 流水线运行机制评论触发 多 Stage 编排流水线通过PR 评论触发在 Pull Request 下评论/compile即启动。依据 CI 流水线配置指导 · 流水线触发触发需要同时配置两个事件pr_comment标识预合并pre-mergeCI 系统据此将本次运行标记为预合并流水线pull_request_comment标准 PR 评论触发事件comments字段用正则^(?:\/)?compile*决定何时启动。流水线整体按Stage 串行、Stage 内 Job 并行编排Stage 1 解析各阶段镜像并生成 PR 变更文件清单Stage 2 并行执行编译x86/arm与代码检查codecheck/staticcheckStage 3 并行执行各模块单元测试Stage 4可选合并各模块覆盖率生成增量报告。各 Job 运行在独立容器中工作区不共享通过 OBS 中转制品例如 CI 流水线配置指导 · OBS 制品中转机制 所述。1.3 FAQ 的定位与使用时机ci_faq.md是社区沉淀的常见问题速查手册定位在 PR 流水线异常排查操作指南 的问题定位指导环节当流水线运行结束后先看 PR 评论区的任务状态FAILED标记点击失败任务跳转日志用 CtrlF/CommandF 搜索error关键字定位核心错误再根据错误类型匹配本文档获取标准化解决方案。也就是说本文档是排查流程的最后一公里——从错误现象直接映射到解决方案。二、流水线触发失败Q1流水线评论后评论区很久没有反应现象开发者在 PR 评论区输入/compile后等待较长时间评论区仍没有任何回复pre_comment预评论与流水线均未出现。根因分析流水线启动前的准备 Job 需要拉取目标分支主干代码并与 PR 变更进行合并操作以生成变更文件清单。依据 CI 流水线配置指导 · get-prget-praction 的职责就是拉取目标分支并生成 PR 变更文件清单这是所有后续检查的基础。当出现以下两种情况时合并操作会异常流水线无法正常推进代码冲突PR 分支与主干在相同区域都有修改git merge无法自动合并落后主干过多PR 基于较早的 commit 创建与主干差异过大合并过程失败或耗时过长。解决方案在本地将主干分支的最新提交合入或 rebase到自己的 PR 分支解决可能存在的冲突推送后再回到 PR 评论区重新评论/compile触发。补充说明如果认为流水线卡住属于偶发问题而非代码问题也可以使用 PR 顶部的重试按钮——该按钮位于PR 顶部标签栏 → 检查处重试只会执行原先失败的 FAILED 任务与重新评论触发整条流水线不同见 ci_guide.md · FAILED 任务重试。三、静态检查失败Q1codecheck 任务执行失败报错信息为 git merge command error现象codecheck 任务日志中出现git merge command error报错任务最终标记为FAILED报错解读从日志结构看该报错发生在 codecheck 任务的执行execute阶段。CI 平台在执行代码检查前需要先把 PR 的变更内容合并到目标分支的基线代码上git merge正是这一合并动作的执行入口。报错信息git merge command error意味着合并命令执行失败后续检查步骤因此无法在正确的代码基线上运行。根因分析依据 FAQ 的结论该问题的本质是主仓 commit 历史与 fork 仓的 commit 历史不同。当 PR 来自 fork 仓库时若 fork 仓没有同步主仓的历史例如 fork 时间过早、历史被改写、或 PR 分支基于过期 commitgit merge会因为历史分叉或缺失共同基线而失败。解决方案重新拉取同步主仓代码。开发者应 fetch 主仓的最新提交并合并到自己的分支使 fork 仓的历史与主仓对齐推送后重新触发 codecheck。补充说明codecheck 是静态检查体系中最核心的门禁之一。依据 ci_guide.md · 检查项概览codecheck_{xxx}覆盖安全类检查算法逻辑安全性、敏感信息如密钥/明文密码清理、代码注入风险与质量类检查危险函数调用、重复文件/代码片段、代码规范违规、语法错误、潜在空指针/数组越界等。同一检查阶段还包含antiposion恶意文件扫描、SCA开源引用合规、codecheck_PrPR 内容合规与codecheck_precommit代码格式与敏感信息筛查等任务它们都依赖get-pr产出的变更文件清单因此保证 PR 分支与主干历史同步、冲突清零是全部静态检查顺利执行的前提。四、单元测试失败Q1单元测试任务执行失败报错信息为 line coverage is blow xx, add coverage result is fail现象UT 任务日志中出现类似line coverage is below xx, add coverage result is failed的报错任务状态为FAILED报错解读日志中先输出本次 UT 计算得到的行覆盖率数值例如图中场景为line coverage is 75.0%随后输出line coverage is below 90, add coverage result is failed最后以非零返回码如ret255结束。这表示本次 PR 变更涉及代码的行覆盖率低于仓库预设的阈值示例场景为 90覆盖率门禁判定失败。根因分析依据 ci_guide.md · 单元测试检查项UT 任务的通过标准是测试用例运行无失败、代码覆盖率不低于代码仓预设阈值。报错说明代码覆盖率不达标——新增或修改的代码缺少足够的单元测试用例覆盖导致增量行覆盖率被拉到阈值以下。解决方案为本次 PR 变更涉及的代码补充对应的单元测试用例尽量覆盖新增分支、异常路径与边界条件提升行覆盖率到阈值以上重新触发流水线。补充说明CANN 社区的 UT 门禁是增量覆盖率而非简单的全量覆盖率。从实现机制看UT 执行后由ut-cov-reportaction 处理覆盖率数据依据 CI 流水线配置指导 · ut-cov-report它支持两种模式cov模式UT 执行后调用根据ut_process输出进一步区分——ut_processcoverage时查找并重命名coverage_ut_type.info供后续合并ut_processut_cov时统计增量覆盖率并打包ut_cov_ut_type.tar.gzreport模式可选 Stage 4下载各模块覆盖率文件合并生成增量覆盖率报告。由此可见line coverage is below xx的判定正发生在ut_cov路径的增量覆盖率统计环节。补充用例后重新触发时建议同时关注ut.sh脚本按ut_type分发如acl、rts_v201是否覆盖到本次变更的模块参见 CI 流水线配置指导 · UT 脚本。五、PR 流水线异常排查方法论当遇到 FAQ 未直接覆盖的错误时可以遵循 ci_guide.md · 问题定位指导 提供的五步排查流程查看 PR 内容与流水线运行结果流水线运行结束后系统自动在 PR 评论区写入完整运行结果异常任务项会明确标记为FAILEDAPI_Check若为WARNING会打上api_ckeck_failed标签不影响合入但 Committer 需评估接口变更影响。跳转查看流水线日志在运行结果表格中点击对应任务行的链接进入流水线运行详情页点击FAILED任务节点查看详细日志也可通过下载按钮将完整日志保存至本地分析。分析日志中的错误信息打开失败任务日志后用 CtrlF/CommandFmacOS 为 CommandF搜索error不区分大小写快速定位核心错误并结合上下文判断错误发生在编译、测试还是合规检查环节。匹配 FAQ 获取解决方案根据定位到的错误类型编译失败、SCA 合规检查失败、单元测试覆盖率不达标等匹配本文档对应章节获取标准化解决方案。FAILED 任务重试若判定失败属于偶发问题而非代码问题可点击 PR 顶部检查处的重试按钮仅重跑原先失败的 FAILED 任务。排查过程中还需要正确理解任务状态语义ci_guide.md · 状态说明 给出了完整的状态字典状态说明备注 running任务执行中—⏳ waiting任务待执行待调度执行或因资源问题排队❌ FAILED任务执行结果失败静态检查类告警存在检查未通过与检查失败两种场景分别通过日志链接或失败原因排查⚠️ WARNING任务执行结果失败不影响合入检查项未正式作为门禁试运行阶段✅ SUCCESS任务执行成功—⚪ ABORTED任务执行中止关联任务失败未执行任务自动中止六、FAQ 之外的求助渠道若本文档未覆盖当前错误场景可按以下渠道升级求助依据 docs/services.md组件仓库 CIE 支撑矩阵涉及编译构建异常、UT 执行异常、冒烟测试异常、静态检查结果屏蔽审核、代码合入异常等问题优先联系对应组件仓库的 CIE持续集成工程师如cann/opbase、cann/ops-nn、cann/runtime、cann/hccl等均有专属支撑人。基础设施支撑矩阵涉及流水线启动异常、任务排队、静态检查配置等基础设施问题可联系基础设施团队其中新建流水线静态检查AI 技能门禁 CI 排障均有对应支撑人。反馈建议向支撑人员反馈时建议附带失败任务的流水线链接、错误日志片段与 PR 编号可显著加快定位效率。七、更新日志更新时间更新内容更新人2026-01-21初始化 FAQ添加流水线触发失败、静态检查失败、单元测试失败 3 大类常见问题社区基础设施团队本 FAQ 由社区基础设施团队维护随着 CI 工程检查项的演进持续扩充。开发者可将实际遇到的新问题场景反馈至 docs/services.md 所列支撑渠道经确认后沉淀为标准条目丰富社区的排障知识库。【免费下载链接】infrastructure本仓库用于托管CANN社区基础设施团队的公开信息包括不限于会议日程成员信息服务文档和配置等信息项目地址: https://gitcode.com/cann/infrastructure创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CANN 社区 CI 流水线故障排查实战指南：触发失败、静态检查与单元测试常见问题 FAQ 解析
CANN 社区 CI 流水线故障排查实战指南触发失败、静态检查与单元测试常见问题 FAQ 解析【免费下载链接】infrastructure本仓库用于托管CANN社区基础设施团队的公开信息包括不限于会议日程成员信息服务文档和配置等信息项目地址: https://gitcode.com/cann/infrastructureCANN 社区通过 GitCode CI 流水线对每一个 Pull Request 执行编译构建、静态检查、单元测试等质量门禁任何一环失败都会阻塞代码合入。本指南以仓库 docs/ci/ci_faq.md 为骨架系统梳理开发者最常遇到的三大类 CI 故障——流水线触发失败、codecheck 静态检查失败、单元测试覆盖率不达标——并逐一给出现象描述、根因分析与可落地的解决方案。读完本文你将掌握从评论区无反应到覆盖率红线等典型异常的标准处置流程并能结合 CI 流水线配置指导 与 CI 工程检查项概览 理解这些问题背后的触发机制、Job 编排与覆盖率判定逻辑。目录快速检索一、CANN 社区 CI 工程与 FAQ 定位二、流水线触发失败三、静态检查失败四、单元测试失败五、PR 流水线异常排查方法论六、FAQ 之外的求助渠道七、更新日志一、CANN 社区 CI 工程与 FAQ 定位1.1 检查项全景三类质量门禁CANN 社区 CI 工程的检查项分为静态检查、编译构建、测试三大类覆盖代码提交到合入的全过程。依据 docs/ci/ci_guide.md 中的检查项概览主要任务包括静态检查codecheck_{xxx}安全与质量类静态代码检查、antiposion_{xxx}恶意文件全量扫描、SCA_{xxx}开源引用合规性检查、codecheck_PrPR 内容合规性校验如空文件、二进制文件混入、PR 描述完整性、API_CheckAPI 接口兼容性全量校验、StaticCheck_*系列md 文档的拼写、资源存在性、链接有效性、HTML 标签闭合、Markdown 格式规范检查、codecheck_precommit代码格式化与敏感信息筛查。编译构建Compile_{xxx}_X86与Compile_{xxx}_ARM分别在 x86 与 ARM 平台完成源码编译、依赖拉取与可执行文件生成。测试UT_{xxx}单元测试含覆盖率门禁、ST_{xxx}系统集成测试、PreSmoke_{xxx}冒烟测试。评论pre_comment流水线触发后的预评论与last_comment执行完成后的总结评论汇总成功/失败明细、失败日志、编译产物与覆盖率报告链接。FAQ 聚焦的正是其中最常出问题的环节流水线触发对应评论环节与 get-pr 合并、静态检查codecheck与单元测试UT 覆盖率门禁。1.2 流水线运行机制评论触发 多 Stage 编排流水线通过PR 评论触发在 Pull Request 下评论/compile即启动。依据 CI 流水线配置指导 · 流水线触发触发需要同时配置两个事件pr_comment标识预合并pre-mergeCI 系统据此将本次运行标记为预合并流水线pull_request_comment标准 PR 评论触发事件comments字段用正则^(?:\/)?compile*决定何时启动。流水线整体按Stage 串行、Stage 内 Job 并行编排Stage 1 解析各阶段镜像并生成 PR 变更文件清单Stage 2 并行执行编译x86/arm与代码检查codecheck/staticcheckStage 3 并行执行各模块单元测试Stage 4可选合并各模块覆盖率生成增量报告。各 Job 运行在独立容器中工作区不共享通过 OBS 中转制品例如 CI 流水线配置指导 · OBS 制品中转机制 所述。1.3 FAQ 的定位与使用时机ci_faq.md是社区沉淀的常见问题速查手册定位在 PR 流水线异常排查操作指南 的问题定位指导环节当流水线运行结束后先看 PR 评论区的任务状态FAILED标记点击失败任务跳转日志用 CtrlF/CommandF 搜索error关键字定位核心错误再根据错误类型匹配本文档获取标准化解决方案。也就是说本文档是排查流程的最后一公里——从错误现象直接映射到解决方案。二、流水线触发失败Q1流水线评论后评论区很久没有反应现象开发者在 PR 评论区输入/compile后等待较长时间评论区仍没有任何回复pre_comment预评论与流水线均未出现。根因分析流水线启动前的准备 Job 需要拉取目标分支主干代码并与 PR 变更进行合并操作以生成变更文件清单。依据 CI 流水线配置指导 · get-prget-praction 的职责就是拉取目标分支并生成 PR 变更文件清单这是所有后续检查的基础。当出现以下两种情况时合并操作会异常流水线无法正常推进代码冲突PR 分支与主干在相同区域都有修改git merge无法自动合并落后主干过多PR 基于较早的 commit 创建与主干差异过大合并过程失败或耗时过长。解决方案在本地将主干分支的最新提交合入或 rebase到自己的 PR 分支解决可能存在的冲突推送后再回到 PR 评论区重新评论/compile触发。补充说明如果认为流水线卡住属于偶发问题而非代码问题也可以使用 PR 顶部的重试按钮——该按钮位于PR 顶部标签栏 → 检查处重试只会执行原先失败的 FAILED 任务与重新评论触发整条流水线不同见 ci_guide.md · FAILED 任务重试。三、静态检查失败Q1codecheck 任务执行失败报错信息为 git merge command error现象codecheck 任务日志中出现git merge command error报错任务最终标记为FAILED报错解读从日志结构看该报错发生在 codecheck 任务的执行execute阶段。CI 平台在执行代码检查前需要先把 PR 的变更内容合并到目标分支的基线代码上git merge正是这一合并动作的执行入口。报错信息git merge command error意味着合并命令执行失败后续检查步骤因此无法在正确的代码基线上运行。根因分析依据 FAQ 的结论该问题的本质是主仓 commit 历史与 fork 仓的 commit 历史不同。当 PR 来自 fork 仓库时若 fork 仓没有同步主仓的历史例如 fork 时间过早、历史被改写、或 PR 分支基于过期 commitgit merge会因为历史分叉或缺失共同基线而失败。解决方案重新拉取同步主仓代码。开发者应 fetch 主仓的最新提交并合并到自己的分支使 fork 仓的历史与主仓对齐推送后重新触发 codecheck。补充说明codecheck 是静态检查体系中最核心的门禁之一。依据 ci_guide.md · 检查项概览codecheck_{xxx}覆盖安全类检查算法逻辑安全性、敏感信息如密钥/明文密码清理、代码注入风险与质量类检查危险函数调用、重复文件/代码片段、代码规范违规、语法错误、潜在空指针/数组越界等。同一检查阶段还包含antiposion恶意文件扫描、SCA开源引用合规、codecheck_PrPR 内容合规与codecheck_precommit代码格式与敏感信息筛查等任务它们都依赖get-pr产出的变更文件清单因此保证 PR 分支与主干历史同步、冲突清零是全部静态检查顺利执行的前提。四、单元测试失败Q1单元测试任务执行失败报错信息为 line coverage is blow xx, add coverage result is fail现象UT 任务日志中出现类似line coverage is below xx, add coverage result is failed的报错任务状态为FAILED报错解读日志中先输出本次 UT 计算得到的行覆盖率数值例如图中场景为line coverage is 75.0%随后输出line coverage is below 90, add coverage result is failed最后以非零返回码如ret255结束。这表示本次 PR 变更涉及代码的行覆盖率低于仓库预设的阈值示例场景为 90覆盖率门禁判定失败。根因分析依据 ci_guide.md · 单元测试检查项UT 任务的通过标准是测试用例运行无失败、代码覆盖率不低于代码仓预设阈值。报错说明代码覆盖率不达标——新增或修改的代码缺少足够的单元测试用例覆盖导致增量行覆盖率被拉到阈值以下。解决方案为本次 PR 变更涉及的代码补充对应的单元测试用例尽量覆盖新增分支、异常路径与边界条件提升行覆盖率到阈值以上重新触发流水线。补充说明CANN 社区的 UT 门禁是增量覆盖率而非简单的全量覆盖率。从实现机制看UT 执行后由ut-cov-reportaction 处理覆盖率数据依据 CI 流水线配置指导 · ut-cov-report它支持两种模式cov模式UT 执行后调用根据ut_process输出进一步区分——ut_processcoverage时查找并重命名coverage_ut_type.info供后续合并ut_processut_cov时统计增量覆盖率并打包ut_cov_ut_type.tar.gzreport模式可选 Stage 4下载各模块覆盖率文件合并生成增量覆盖率报告。由此可见line coverage is below xx的判定正发生在ut_cov路径的增量覆盖率统计环节。补充用例后重新触发时建议同时关注ut.sh脚本按ut_type分发如acl、rts_v201是否覆盖到本次变更的模块参见 CI 流水线配置指导 · UT 脚本。五、PR 流水线异常排查方法论当遇到 FAQ 未直接覆盖的错误时可以遵循 ci_guide.md · 问题定位指导 提供的五步排查流程查看 PR 内容与流水线运行结果流水线运行结束后系统自动在 PR 评论区写入完整运行结果异常任务项会明确标记为FAILEDAPI_Check若为WARNING会打上api_ckeck_failed标签不影响合入但 Committer 需评估接口变更影响。跳转查看流水线日志在运行结果表格中点击对应任务行的链接进入流水线运行详情页点击FAILED任务节点查看详细日志也可通过下载按钮将完整日志保存至本地分析。分析日志中的错误信息打开失败任务日志后用 CtrlF/CommandFmacOS 为 CommandF搜索error不区分大小写快速定位核心错误并结合上下文判断错误发生在编译、测试还是合规检查环节。匹配 FAQ 获取解决方案根据定位到的错误类型编译失败、SCA 合规检查失败、单元测试覆盖率不达标等匹配本文档对应章节获取标准化解决方案。FAILED 任务重试若判定失败属于偶发问题而非代码问题可点击 PR 顶部检查处的重试按钮仅重跑原先失败的 FAILED 任务。排查过程中还需要正确理解任务状态语义ci_guide.md · 状态说明 给出了完整的状态字典状态说明备注 running任务执行中—⏳ waiting任务待执行待调度执行或因资源问题排队❌ FAILED任务执行结果失败静态检查类告警存在检查未通过与检查失败两种场景分别通过日志链接或失败原因排查⚠️ WARNING任务执行结果失败不影响合入检查项未正式作为门禁试运行阶段✅ SUCCESS任务执行成功—⚪ ABORTED任务执行中止关联任务失败未执行任务自动中止六、FAQ 之外的求助渠道若本文档未覆盖当前错误场景可按以下渠道升级求助依据 docs/services.md组件仓库 CIE 支撑矩阵涉及编译构建异常、UT 执行异常、冒烟测试异常、静态检查结果屏蔽审核、代码合入异常等问题优先联系对应组件仓库的 CIE持续集成工程师如cann/opbase、cann/ops-nn、cann/runtime、cann/hccl等均有专属支撑人。基础设施支撑矩阵涉及流水线启动异常、任务排队、静态检查配置等基础设施问题可联系基础设施团队其中新建流水线静态检查AI 技能门禁 CI 排障均有对应支撑人。反馈建议向支撑人员反馈时建议附带失败任务的流水线链接、错误日志片段与 PR 编号可显著加快定位效率。七、更新日志更新时间更新内容更新人2026-01-21初始化 FAQ添加流水线触发失败、静态检查失败、单元测试失败 3 大类常见问题社区基础设施团队本 FAQ 由社区基础设施团队维护随着 CI 工程检查项的演进持续扩充。开发者可将实际遇到的新问题场景反馈至 docs/services.md 所列支撑渠道经确认后沉淀为标准条目丰富社区的排障知识库。【免费下载链接】infrastructure本仓库用于托管CANN社区基础设施团队的公开信息包括不限于会议日程成员信息服务文档和配置等信息项目地址: https://gitcode.com/cann/infrastructure创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
