昇腾 HCCL 开源仓 CI 失败诊断与修复指南从/compile触发到passed的完整闭环【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hcclHCCLHuawei Collective Communication Library是 CANN 的核心集合通信库其开源仓库通过 GitCode 上的 openlibing 平台承载 CI 流水线。本文聚焦该仓库 PR 场景下 CI 失败的系统性定位与修复方法从失败信息的获取、常见失败模式的对照修复、codecheck 静态规则的处理到环境坑的排查与已知非阻塞项的判定最终给出修复 → 本地验证 → 重触发 → 轮询通过的完整闭环。读完本文你将能够独立完成 HCCL 仓任意一次 CI 失败的三步定位取日志 → grep 根因 → 对照修复并能区分代码问题与平台/环境抖动。一、CI 体系概览openlibing 平台与任务清单HCCL 仓库的 CI 由 openlibing 平台承载触发方式是在 PR 下评论/compile由贡献流程 skill 的--submit-pr子命令在创建 PR 后自动完成见 .agents/skills/hccl-contribute/scripts/contribute.py。一次/compile会拉起如下任务任务职责Compile_Ascend_X86 / ARM_ubuntu24编译验证对应产物形态由构建脚本决定codecheck codestyle静态检查覆盖 C 与 Python 代码规范staticcheckmarkdownlint 等Markdown 文档格式检查UT / ST单元测试与系统测试API_Check对外 API 兼容性检查precommitOAT开源合规检查许可头、文件类型PreSmoke冒烟验证任务失败后GitCode 会在 PR 上打ci-pipeline-failed标签通过则打ci-pipeline-passed。这些标签语义由脚本中的CI_LABEL_RUNNING/PASSED/FAILED常量固化轮询时还会用saw_running状态机防止旧标签误判见 .agents/skills/hccl-contribute/scripts/contribute.py 中的--ci-status实现。二、三步诊断路径取日志、grep 根因、对照修复无论失败发生在哪个任务诊断都遵循同一套流程取失败信息pre-commit/markdownlint类任务的日志可从OBS 直链免登录下载——脚本--ci-logs子命令已内置 OBS 日志基地址OBS_LOG_BASE常量与流水线链接收集逻辑一条命令即可拉取python3 .agents/skills/hccl-contribute/scripts/contribute.py --ci-logs --repo hccl --pr N --output-dir ./ci_logs其他任务需查看cann-robot 评论里的流水线链接在浏览器打开任务详情页查看日志。grep 定位根因行grep -E error|Error|ERROR|FAILED|exit 1 日志文件对照下文失败模式表修复若判定为平台问题见已知非阻塞判定节则记录后直接重触发。三、C 变更常见失败模式仓主体语言HCCL 仓以 C 为主体语言集合通信算子实现在 src/ops/通用逻辑在 src/common/C 变更占了 CI 失败的大头。下表是实践中归纳的失败模式、日志特征与修复方式失败模式特征修复编译错误Compile_X86/ARM日志error:定位文件行号本地复现Linux 环境bash build.sh --pkg命令以仓 AGENTS.md 第 4 节为准注意 CMake 缓存会掩盖错误目录结构变更后须清 build 目录重编clang-format 风格precommitprecommit 失败clang-format hook 报 diffclang-format -i 文件版本须与 .pre-commit-config.yaml 的 rev 一致当前为 v18.1.8只对本次改动的文件跑勿全仓格式化OAT 许可头precommit日志License Header Invalid新增源文件头加 CANN-2.0 许可头与仓内已有 C 文件逐字节一致对照 src/ 下任一.ccOAT 二进制误判precommitInvalid File Type — Content: binary文件注释改纯英文 ASCII中文多字节字符被 chardet 误判UT/ST 用例失败UT_Test/ST_Test 任务失败先看是否环境抖动见已知非阻塞判定真实失败按日志定位用例本地bash build.sh -u-s复现链接错误undefined reference to检查新增符号是否漏加进 CMakeLists.txt 的目标源文件列表acl* 符号未定义通常是本地 CANN 版本差异CI 不报则不阻塞add_subdirectory 被注释特定模块 .o 缺失、chmod 报错恢复被注释的add_subdirectoryBUILD_OPEN_PROJECT 依赖完整目录树目录重命名遗漏fatal error: xxx.h: No such file全仓 grep 旧路径含 experimental/CMakeLists、#include相对路径、cmake/、build.sh、classify_rule.yaml、blacklist.txtCMake 缓存掩盖本地增量通过 CI 失败rm -rf build*后干净重编验证codecheck 静态告警codecheck 任务失败详情页G.*规则浏览器打开 cann-robot 评论里的 entryCheckDashCode 链接看告警清单按规则修复几个关键点结合源码展开本地复现命令仓根 AGENTS.md 第 4 节给出了完整构建矩阵——bash build.sh --pkg编译 host 包默认、bash build.sh -u编译并运行 UT、bash build.sh -s编译并运行 ST、--static/--asan/--custom_ops_pathPATH/-j64等变体。推送前优先本地验证--pkg UT ST这是减少 CI 往返成本最有效的手段。clang-format 版本一致性.pre-commit-config.yaml 中 clang-format hook 固定rev: v18.1.8本地clang-format版本必须与此一致否则格式化结果可能不同。本地跑法pip3 install pre-commit pre-commit run --files 改动文件。OAT 检查pre-commit 阶段由 .pre-commit-config.yaml 中的oat-checkhookrepo 为 compliance v1.0.5执行检查许可证头与文件类型禁止二进制/归档文件。本地也可用bash scripts/oat_check.sh 文件单独验证exit0 才通过。新增源文件的 CANN-2.0 许可头应与仓内已有.cc文件逐字节一致。目录重命名是高频事故HCCL 源码结构敏感重命名目录后必须在CMakeLists.txt、#include相对路径、cmake/、build.sh、classify_rule.yaml、blacklist.txt中同步更新引用且要覆盖 experimental/ 下的试验性代码该目录不编入商用版本但同样是仓库的一部分遗漏会引发No such file类编译错误。AGENTS.md 第 8 节也明确要求涉及src/目录重命名/移动时同步检查 CMakeLists、测试 include 路径并清理 build 目录后重新验证。四、codecheck 规则与修复模式新增脚本文件常遇codecheck 不仅检查 C对 .agents/ 下的 Python 脚本也做全量检查C 告警在 codecheck 任务详情页查看具体规则与行号。以下规则是新增脚本文件时最容易踩中的规则含义修复模式G.LOG.02禁 print用loggingbasicConfig LOG.infoG.FMT.02行宽超 120拆行按字符数算中文 1 字符G.FMT.03嵌套 def 前缺空行函数体内定义函数前补空行G.FMT.04标点后多余空格删多余空格G.FMT.05/07import 位置/顺序import 全部放顶部G.FNM.03函数参数过多5用类如 NamedTuple封装参数G.CTL.03if 布尔表达式过多3提取中间变量或辅助函数G.EDV.05外部命令无绝对路径shutil.which(git)解析绝对路径G.VAR.03覆盖外部标识符改名避免覆盖顶部 importG.EXP.04推导式子句过多2改普通 for 循环G.CLS.06类的方法排列helper 应在测试方法后helper 方法移到类定义末尾或提升为模块级函数G.NAM.02禁单字符变量名l/I/o改有含义名item/entry 等G.ERR.09同一 except 捕父子类异常如 HTTPErrorURLError只捕父类这些规则在仓库自带脚本中有直接体现例如 .agents/skills/hccl-contribute/scripts/contribute.py 使用logging.basicConfigLOG.info输出对应 G.LOG.02、用shutil.which(git)解析 git 路径对应 G.EDV.05、把 import 全部置于文件顶部对应 G.FMT.05/07可作为通过检查的参考样例。五、markdownlintstaticcheck_md_checkMarkdown 文档不合规会在 staticcheck 的 md_check 任务中按行号报出。三个高频规则MD032列表前缺空行MD029有序列表编号风格不一致MD001标题层级跳跃修复方式就是按日志行号逐条改格式。HCCL 仓的文档编写还遵循 AGENTS.md 第 6 节的规范中文文档在docs/zh/、英文在docs/en/、API 文档 PascalCase 命名、环境变量文档 UPPER_SNAKE_CASE 命名改文档前先对照这些约束可少走弯路。六、环境坑本地跑 UT/ST 前先排查全部实测踩过以下环境问题在 CI 中不一定出现但本地复现 UT/ST 时几乎都会踩到建议在跑测试前逐项排查症状根因处置编译报acl* 符号 was not declaredmaster 用了新版 CANN 才有的符号本机 CANN 落后grep 符号 $ASCEND_HOME_PATH/include/acl/acl_rt.h确认后按 docs/zh/build/build.md 镜像站最新时间戳目录下载 toolkit 更新勿改代码迁就旧 CANNUT 的 aicpu 套件报ccl_kernel.json is not a valid real path未安装 device kernel须build.sh --pkg --full并安装到 CANN具体为chmod -R uw $CANN bash build_out/cann-hccl_*.run --full --install-path$CANN装完重跑且执行测试的 shell 须已 source set_env.shWSLsource set_env.sh后$ASCEND_HOME_PATH仍为空set_env.sh 内read -r需要 stdinbash -c source ...内联方式静默失败用 heredocwsl EOF ... EOF方式执行并回显校验变量ARM 环境 UT 大面积SIGILL/Illegal instruction37 个测试 dumped core或 mockcppVirtual method address should be odd失败mockcpp 2.7 的自由函数打桩MOCKER(libc函数)的 trampoline在 aarch64 gcc 10 系组合下生成非法指令gdb 可见被桩函数首指令被udf #0覆盖仓内 CI 的 ARM 通道用 gcc-14 镜像无此问题master 代码本身支持 ARM工具链限制而非代码问题用 master 干净 worktree 对照确认后可判定环境性失败在 gcc-14 环境CI 或 x86同用例通过即非阻塞前两个环境坑的处置细节与 docs/zh/build/build.md 的构建/安装章节严格对应--pkg --full生成 host device 包安装命令bash ./build_out/cann-hccl_version_linux-arch.run --full会将编译产物替换已安装 CANN Toolkit 中的 HCCL 相关软件而source CANN安装路径/cann/set_env.sh echo $ASCEND_HOME_PATH是环境是否就绪的最小校验。ut 执行建议用bash build.sh -uLLT 测试入口。七、已知非阻塞判定别在错误的地方浪费力气并非所有FAILED都是你的代码问题。以下情形已被反复验证为非阻塞可直接跳过或重触发UT_Test FAILED ≠ 测试失败日志里[ PASSED ]/[ FAILED ]只看测试本身增量覆盖率脚本get_ai_inc_cov.py报错导致的 FAILED 不影响ci_state_passed。先重触发一轮再判断。codecheck DEV-CODECI-35002CI 平台级错误构建任务执行失败与代码无关重触发即可。api-check-failed与ci-pipeline-passed并存后者是 stale 残留标签聚合流水线成功已含 API_Check不需要重触发。流水线过期提示GitCode 门禁校验流水线 commitID PR 当前 headpush 新 commit 后旧 passed 失效属正常重新/compile即可。与此配套--ci-status的状态语义需要理解见 .agents/skills/hccl-contribute/SKILL.md Step 6running运行中/passed本轮通过/failed本轮失败/finishingrunning 已消失、终态标签未上稍等再查/stale无 running 历史的残留标签不可作为本轮结论/not_triggered从未触发需评论/compile/timeout轮询超时稍后重查。每次 push 后必须重新/compilepush 会自动失效旧ci-pipeline-passed且不要重复触发会打断在跑轮次并留下误导性 failed 标签。八、修复闭环从失败到passed的完整循环一次 CI 修复的完整闭环如下修复按失败模式表与 codecheck/markdownlint 规则修改代码本地验证C 变更按 AGENTS.md 构建命令bash build.sh --pkg必要时-u/-s验证skill 脚本跑单测python3 -m unittest discover -s .agents/skills/hccl-contribute/scripts -p test_contribute.pycommitgit user.email必须与 CLA 签署邮箱一致否则 PR 会被打cann-cla/nopush评论/compile单次勿重复轮询--ci-status --wait默认 60s 间隔 / 30min 超时直至passed。若反复失败且判定为环境/平台问题可在 master 干净 worktree 上对照复现以佐证环境性失败结论例如 ARM 工具链 SIGILL 场景。整套流程在 .agents/skills/hccl-contribute/SKILL.md 中被固化为可独立运行的子流程Step 6 CI 监控 / Step 7 CI 失败修复诊断规则即本文所讲的 .agents/skills/hccl-contribute/references/ci-triage.md。掌握这份手册配合--ci-logs/--ci-status两个命令即可在 HCCL 仓的贡献流程中高效地把 CI 跑绿。【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 昇腾 HCCL 开源仓 CI 失败诊断与修复指南：从 `/compile` 触发到 `passed` 的完整闭环
昇腾 HCCL 开源仓 CI 失败诊断与修复指南从/compile触发到passed的完整闭环【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hcclHCCLHuawei Collective Communication Library是 CANN 的核心集合通信库其开源仓库通过 GitCode 上的 openlibing 平台承载 CI 流水线。本文聚焦该仓库 PR 场景下 CI 失败的系统性定位与修复方法从失败信息的获取、常见失败模式的对照修复、codecheck 静态规则的处理到环境坑的排查与已知非阻塞项的判定最终给出修复 → 本地验证 → 重触发 → 轮询通过的完整闭环。读完本文你将能够独立完成 HCCL 仓任意一次 CI 失败的三步定位取日志 → grep 根因 → 对照修复并能区分代码问题与平台/环境抖动。一、CI 体系概览openlibing 平台与任务清单HCCL 仓库的 CI 由 openlibing 平台承载触发方式是在 PR 下评论/compile由贡献流程 skill 的--submit-pr子命令在创建 PR 后自动完成见 .agents/skills/hccl-contribute/scripts/contribute.py。一次/compile会拉起如下任务任务职责Compile_Ascend_X86 / ARM_ubuntu24编译验证对应产物形态由构建脚本决定codecheck codestyle静态检查覆盖 C 与 Python 代码规范staticcheckmarkdownlint 等Markdown 文档格式检查UT / ST单元测试与系统测试API_Check对外 API 兼容性检查precommitOAT开源合规检查许可头、文件类型PreSmoke冒烟验证任务失败后GitCode 会在 PR 上打ci-pipeline-failed标签通过则打ci-pipeline-passed。这些标签语义由脚本中的CI_LABEL_RUNNING/PASSED/FAILED常量固化轮询时还会用saw_running状态机防止旧标签误判见 .agents/skills/hccl-contribute/scripts/contribute.py 中的--ci-status实现。二、三步诊断路径取日志、grep 根因、对照修复无论失败发生在哪个任务诊断都遵循同一套流程取失败信息pre-commit/markdownlint类任务的日志可从OBS 直链免登录下载——脚本--ci-logs子命令已内置 OBS 日志基地址OBS_LOG_BASE常量与流水线链接收集逻辑一条命令即可拉取python3 .agents/skills/hccl-contribute/scripts/contribute.py --ci-logs --repo hccl --pr N --output-dir ./ci_logs其他任务需查看cann-robot 评论里的流水线链接在浏览器打开任务详情页查看日志。grep 定位根因行grep -E error|Error|ERROR|FAILED|exit 1 日志文件对照下文失败模式表修复若判定为平台问题见已知非阻塞判定节则记录后直接重触发。三、C 变更常见失败模式仓主体语言HCCL 仓以 C 为主体语言集合通信算子实现在 src/ops/通用逻辑在 src/common/C 变更占了 CI 失败的大头。下表是实践中归纳的失败模式、日志特征与修复方式失败模式特征修复编译错误Compile_X86/ARM日志error:定位文件行号本地复现Linux 环境bash build.sh --pkg命令以仓 AGENTS.md 第 4 节为准注意 CMake 缓存会掩盖错误目录结构变更后须清 build 目录重编clang-format 风格precommitprecommit 失败clang-format hook 报 diffclang-format -i 文件版本须与 .pre-commit-config.yaml 的 rev 一致当前为 v18.1.8只对本次改动的文件跑勿全仓格式化OAT 许可头precommit日志License Header Invalid新增源文件头加 CANN-2.0 许可头与仓内已有 C 文件逐字节一致对照 src/ 下任一.ccOAT 二进制误判precommitInvalid File Type — Content: binary文件注释改纯英文 ASCII中文多字节字符被 chardet 误判UT/ST 用例失败UT_Test/ST_Test 任务失败先看是否环境抖动见已知非阻塞判定真实失败按日志定位用例本地bash build.sh -u-s复现链接错误undefined reference to检查新增符号是否漏加进 CMakeLists.txt 的目标源文件列表acl* 符号未定义通常是本地 CANN 版本差异CI 不报则不阻塞add_subdirectory 被注释特定模块 .o 缺失、chmod 报错恢复被注释的add_subdirectoryBUILD_OPEN_PROJECT 依赖完整目录树目录重命名遗漏fatal error: xxx.h: No such file全仓 grep 旧路径含 experimental/CMakeLists、#include相对路径、cmake/、build.sh、classify_rule.yaml、blacklist.txtCMake 缓存掩盖本地增量通过 CI 失败rm -rf build*后干净重编验证codecheck 静态告警codecheck 任务失败详情页G.*规则浏览器打开 cann-robot 评论里的 entryCheckDashCode 链接看告警清单按规则修复几个关键点结合源码展开本地复现命令仓根 AGENTS.md 第 4 节给出了完整构建矩阵——bash build.sh --pkg编译 host 包默认、bash build.sh -u编译并运行 UT、bash build.sh -s编译并运行 ST、--static/--asan/--custom_ops_pathPATH/-j64等变体。推送前优先本地验证--pkg UT ST这是减少 CI 往返成本最有效的手段。clang-format 版本一致性.pre-commit-config.yaml 中 clang-format hook 固定rev: v18.1.8本地clang-format版本必须与此一致否则格式化结果可能不同。本地跑法pip3 install pre-commit pre-commit run --files 改动文件。OAT 检查pre-commit 阶段由 .pre-commit-config.yaml 中的oat-checkhookrepo 为 compliance v1.0.5执行检查许可证头与文件类型禁止二进制/归档文件。本地也可用bash scripts/oat_check.sh 文件单独验证exit0 才通过。新增源文件的 CANN-2.0 许可头应与仓内已有.cc文件逐字节一致。目录重命名是高频事故HCCL 源码结构敏感重命名目录后必须在CMakeLists.txt、#include相对路径、cmake/、build.sh、classify_rule.yaml、blacklist.txt中同步更新引用且要覆盖 experimental/ 下的试验性代码该目录不编入商用版本但同样是仓库的一部分遗漏会引发No such file类编译错误。AGENTS.md 第 8 节也明确要求涉及src/目录重命名/移动时同步检查 CMakeLists、测试 include 路径并清理 build 目录后重新验证。四、codecheck 规则与修复模式新增脚本文件常遇codecheck 不仅检查 C对 .agents/ 下的 Python 脚本也做全量检查C 告警在 codecheck 任务详情页查看具体规则与行号。以下规则是新增脚本文件时最容易踩中的规则含义修复模式G.LOG.02禁 print用loggingbasicConfig LOG.infoG.FMT.02行宽超 120拆行按字符数算中文 1 字符G.FMT.03嵌套 def 前缺空行函数体内定义函数前补空行G.FMT.04标点后多余空格删多余空格G.FMT.05/07import 位置/顺序import 全部放顶部G.FNM.03函数参数过多5用类如 NamedTuple封装参数G.CTL.03if 布尔表达式过多3提取中间变量或辅助函数G.EDV.05外部命令无绝对路径shutil.which(git)解析绝对路径G.VAR.03覆盖外部标识符改名避免覆盖顶部 importG.EXP.04推导式子句过多2改普通 for 循环G.CLS.06类的方法排列helper 应在测试方法后helper 方法移到类定义末尾或提升为模块级函数G.NAM.02禁单字符变量名l/I/o改有含义名item/entry 等G.ERR.09同一 except 捕父子类异常如 HTTPErrorURLError只捕父类这些规则在仓库自带脚本中有直接体现例如 .agents/skills/hccl-contribute/scripts/contribute.py 使用logging.basicConfigLOG.info输出对应 G.LOG.02、用shutil.which(git)解析 git 路径对应 G.EDV.05、把 import 全部置于文件顶部对应 G.FMT.05/07可作为通过检查的参考样例。五、markdownlintstaticcheck_md_checkMarkdown 文档不合规会在 staticcheck 的 md_check 任务中按行号报出。三个高频规则MD032列表前缺空行MD029有序列表编号风格不一致MD001标题层级跳跃修复方式就是按日志行号逐条改格式。HCCL 仓的文档编写还遵循 AGENTS.md 第 6 节的规范中文文档在docs/zh/、英文在docs/en/、API 文档 PascalCase 命名、环境变量文档 UPPER_SNAKE_CASE 命名改文档前先对照这些约束可少走弯路。六、环境坑本地跑 UT/ST 前先排查全部实测踩过以下环境问题在 CI 中不一定出现但本地复现 UT/ST 时几乎都会踩到建议在跑测试前逐项排查症状根因处置编译报acl* 符号 was not declaredmaster 用了新版 CANN 才有的符号本机 CANN 落后grep 符号 $ASCEND_HOME_PATH/include/acl/acl_rt.h确认后按 docs/zh/build/build.md 镜像站最新时间戳目录下载 toolkit 更新勿改代码迁就旧 CANNUT 的 aicpu 套件报ccl_kernel.json is not a valid real path未安装 device kernel须build.sh --pkg --full并安装到 CANN具体为chmod -R uw $CANN bash build_out/cann-hccl_*.run --full --install-path$CANN装完重跑且执行测试的 shell 须已 source set_env.shWSLsource set_env.sh后$ASCEND_HOME_PATH仍为空set_env.sh 内read -r需要 stdinbash -c source ...内联方式静默失败用 heredocwsl EOF ... EOF方式执行并回显校验变量ARM 环境 UT 大面积SIGILL/Illegal instruction37 个测试 dumped core或 mockcppVirtual method address should be odd失败mockcpp 2.7 的自由函数打桩MOCKER(libc函数)的 trampoline在 aarch64 gcc 10 系组合下生成非法指令gdb 可见被桩函数首指令被udf #0覆盖仓内 CI 的 ARM 通道用 gcc-14 镜像无此问题master 代码本身支持 ARM工具链限制而非代码问题用 master 干净 worktree 对照确认后可判定环境性失败在 gcc-14 环境CI 或 x86同用例通过即非阻塞前两个环境坑的处置细节与 docs/zh/build/build.md 的构建/安装章节严格对应--pkg --full生成 host device 包安装命令bash ./build_out/cann-hccl_version_linux-arch.run --full会将编译产物替换已安装 CANN Toolkit 中的 HCCL 相关软件而source CANN安装路径/cann/set_env.sh echo $ASCEND_HOME_PATH是环境是否就绪的最小校验。ut 执行建议用bash build.sh -uLLT 测试入口。七、已知非阻塞判定别在错误的地方浪费力气并非所有FAILED都是你的代码问题。以下情形已被反复验证为非阻塞可直接跳过或重触发UT_Test FAILED ≠ 测试失败日志里[ PASSED ]/[ FAILED ]只看测试本身增量覆盖率脚本get_ai_inc_cov.py报错导致的 FAILED 不影响ci_state_passed。先重触发一轮再判断。codecheck DEV-CODECI-35002CI 平台级错误构建任务执行失败与代码无关重触发即可。api-check-failed与ci-pipeline-passed并存后者是 stale 残留标签聚合流水线成功已含 API_Check不需要重触发。流水线过期提示GitCode 门禁校验流水线 commitID PR 当前 headpush 新 commit 后旧 passed 失效属正常重新/compile即可。与此配套--ci-status的状态语义需要理解见 .agents/skills/hccl-contribute/SKILL.md Step 6running运行中/passed本轮通过/failed本轮失败/finishingrunning 已消失、终态标签未上稍等再查/stale无 running 历史的残留标签不可作为本轮结论/not_triggered从未触发需评论/compile/timeout轮询超时稍后重查。每次 push 后必须重新/compilepush 会自动失效旧ci-pipeline-passed且不要重复触发会打断在跑轮次并留下误导性 failed 标签。八、修复闭环从失败到passed的完整循环一次 CI 修复的完整闭环如下修复按失败模式表与 codecheck/markdownlint 规则修改代码本地验证C 变更按 AGENTS.md 构建命令bash build.sh --pkg必要时-u/-s验证skill 脚本跑单测python3 -m unittest discover -s .agents/skills/hccl-contribute/scripts -p test_contribute.pycommitgit user.email必须与 CLA 签署邮箱一致否则 PR 会被打cann-cla/nopush评论/compile单次勿重复轮询--ci-status --wait默认 60s 间隔 / 30min 超时直至passed。若反复失败且判定为环境/平台问题可在 master 干净 worktree 上对照复现以佐证环境性失败结论例如 ARM 工具链 SIGILL 场景。整套流程在 .agents/skills/hccl-contribute/SKILL.md 中被固化为可独立运行的子流程Step 6 CI 监控 / Step 7 CI 失败修复诊断规则即本文所讲的 .agents/skills/hccl-contribute/references/ci-triage.md。掌握这份手册配合--ci-logs/--ci-status两个命令即可在 HCCL 仓的贡献流程中高效地把 CI 跑绿。【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考