CANN 门禁流水线“包安装失败“分层定位实战：以 ops-cv PR 1310 案例拆解 CMake 新旧宏注册冲突

CANN 门禁流水线包安装失败分层定位实战以 ops-cv PR 1310 案例拆解 CMake 新旧宏注册冲突【免费下载链接】infrastructure本仓库用于托管CANN社区基础设施团队的公开信息包括不限于会议日程成员信息服务文档和配置等信息项目地址: https://gitcode.com/cann/infrastructure本文以 CANN 社区 infrastructure 仓库中已验证的排障案例 case_cv1310_pkg.md 为主体完整还原一次 ops-cv PR 门禁流水线包安装失败pkg_install_fail的分层定位过程从 PR 评论逐层下钻到构建日志、用证据链证明构建成功但 .run 安装自检失败的真因是 CMake 新旧宏注册冲突并沉淀出可复用的三级定界与排除项方法论。读完后你可以掌握针对 CI构建成功安装失败类故障的端到端定位流程——包括末尾回溯、目标缺失反查、对照组验证和同因聚合。案例背景一次看起来可能是配置问题的 PR 门禁失败案例对象是cann/ops-cv仓库的 PR 1310「add ROIAlign operator」——在 A5ascend950arch35上新增 ROIAlign 算子。关键事实最新一次 run#1134 FAILEDPR 被打上ci-pipeline-failedapi-check-failed标签提交者的疑问很典型是不是安装的 xml 没有配置好——即怀疑是安装包元数据配置问题而非代码问题。这一疑问恰好是包安装失败类故障最易误导的方向报错发生在安装自检环节直觉上会往安装器配置上猜。而案例的最终结论是安装器的必需库校验行为是正确的包里真的缺库根因在 PR 的 CMake 构建配置。整个定位过程分为分层下钻与日志证据链两段下面按原案例脉络完整展开。五层下钻从 PR 评论到构建日志该案例遵循 pipeline-layered-localizer 技能定义的 L0→L5 分层模型PR → Run → Stage → Job → Step → 日志路径如下引自原案例L0 PR 评论 → 最后一次 /compile(16:37) → run 043f81e6 L1 run#1134 FAILED 3.0min L2 stage: compile FAILED46 job 中仅 8 失败4×A5 编译矩阵全挂 x86/arm/experimental/monitor 全过 L3 job: Compile_A5_x86 等外层报 Sub-pipeline execution failed 内层 Compile [JOB_a5_compile_0] 报 步骤compile_acc执行失败 → 下日志 L4 step: compile_acc FAILED3min 处 L5 日志: cc5ef259…(内层job).zip → 3_compile_acc.log各层判据在技能的分层判据明细layer_criteria.md中有系统定义其中两点值得强调L2 判据的矩阵筛选价值46 个 job 中只有 4 个 A5 编译矩阵 jobx86/arm × 默认/ubuntu24失败x86/arm/experimental/monitor 全部通过。按判据库的逻辑只有特定芯片矩阵挂意味着问题在 ascend950 专属构建路径soc 筛选、专属宏而非公共编译问题。这条判据直接把排查范围从整个 CI收窄到A5 专属的 ops-cv 构建配置。外层/内层 job 成对出现Compile_A5_x86外层 job报的是Sub-pipeline execution failed子流水线引用真正的构建日志挂在 identifier 带_0的内层 jobJOB_a5_compile_0上。这是 GitCode Actions 流水线的结构性特点直接下外层 job 的日志会一无所获详见 api_endpoints.md 中run 详情 vs jobs API一节。另外注意 L0 层以最后一次运行为准的原则PR 评论中可能有多次/compile重试历史定位对象是最后一次 run前几次仅作对照。/compile命令与ci-pipeline-failed标签的语义源头见社区 robot使用指南L2~L4 检查项分类与任务状态语义见 CI工程检查项概览。L5 日志证据链六步还原构建成功安装失败以下六步是原案例的核心内容证据链环环相扣按原始顺序完整继承。第 1 步构建与打包其实成功3_compile_acc.log开头显示构建命令与打包结果[LOG_DO] bash scripts/ci/compile_a5_pkg.sh pr_filelist.txt -j16 [compile_a5_pkg] executing build_cmd: bash build.sh --pkg --opsroi_align --socascend950 ... Self-extractable archive cann-ops-cv-custom-linux.x86_64.run successfully created..run自解包安装包创建成功说明编译和 CPack 打包阶段没有报错。再看 ccacheCloudCache统计miss: 0全命中——编译没有实际压力排除编译本身出问题的假设。构建命令的判读规则--opsx表示只构建指定算子的 PR 增量构建在日志特征模式库 log_patterns.md 的构建命令头一节有说明。第 2 步失败点在 .run 安装自检失败并非发生在编译而是 CI 的冒烟安装环节——用刚打出的包做安装自检./build_out/cann-ops-cv-custom-linux.x86_64.run --install-path/tmp [ops_custom] [INFO] validate shared libraries before installation [ops_custom] [ERROR] Required shared library libcust_opmaster_rt2.0.so was not found in package path. [ops_custom] [ERROR] Shared library validation failed. execute pkg error ::error::ASSERT FAILED: Build ops-cv (expected0, actual1)这里有一个关键的方法论点末尾回溯原则果不是因execute pkg error和::error::ASSERT FAILED: Build ops-cv都是收尾/汇总信号真正根因在它们上方的[ops_custom] [ERROR]段——缺的是libcust_opmaster_rt2.0.so。log_patterns.md 明确将execute pkg error标为 generic 类别ASSERT FAILED同理判据库 classification_rules.md 中包安装卸载验证失败pkg_install_fail小类的核心判据正是\[ops_custom\] \[ERROR\] Required shared library (\S) was not found且注明配套反查动作Built target 缺失 already compiled / dont need tiling → cmake 注册类代码问题。第 3 步包清单确认缺库CPack 段缺哪个库不能只听安装器的报错要用包清单坐实。扫描日志中 CPack 打包阶段的文件清单./packages/...逐文件行确认包内仅有op_proto/lib/linux/x86_64/libcust_opsproto_rt2.0.soproto 定义库没有libcust_opmaster_rt2.0.sotiling/ophost 宿主库。按模式库常见库的语义有 tiling 的算子libcust_opmaster_rt2.0.so是包内必需项——ROIAlign 是带 tiling 的算子所以这个库缺失是真实的包完整性问题而非安装器多嘴。第 4 步编译产物反查目标缺失用目标缺失反查法先搜Built target X无果则反查 target 创建条件与跳过消息该方法完整定义在 log_patterns.md §2日志中Building CXX object的完整列表显示——roi_align_def.cppgen 库、roi_align_infershape.cppophost_cv_infer_obj都编译了roi_align_tiling.cpp从未出现在编译列表中无 cust_opmaster target。即不是编译失败而是 tiling 源文件根本没被 CMake 收集导致下游 target 从未创建。第 5 步cmake 语义消息定根因铁证日志中一行看似不起眼的 cmake 输出成为定根因的铁证-- already compiled roi_align, skip在判据库中already compiled (\S), skip是代码问题高价值子类算子被先执行的宏注册后续宏被去重跳过——新旧宏共存冲突的直接证据。结合 PR 改动面L5→PR files 关联分析完整根因链为PR 在objdetect/roi_align/CMakeLists.txt顶层新增新宏add_all_modules_sources(... TILING_DIR arch35 DISABLE_IN_OPP TRUE)能正确收集 arch35 子目录下的 tiling 源但未删除遗留的op_host/CMakeLists.txt其中仍是旧宏add_modules_sources(OPTYPE roi_align ACLNNTYPE aclnn_exclude)——旧宏的 tiling glob 只扫op_host/*_tiling*.cpp顶层不含 arch35 子目录顶层 CMakeLists 的 foreach 先执行add_subdirectory(op_host)→ 旧宏先跑infershape 编译了、arch35 tiling 源没被收集、roi_align 被标记进 COMPILED_OPS轮到新宏时cmake 去重逻辑输出already compiled roi_align, skip直接跳过 → tiling 源永不编译无 tiling_obj → 无 cust_opmaster target → 打包条件if (TARGET cust_opmaster)为假 → 库不入包 →.run安装自检失败。这条链说明了一个微妙之处.run包创建成功第 1 步与包内容不完整并不矛盾——打包条件静默为假时CMake 不会报错缺库要到安装自检这一关才暴露。第 6 步对照验证仅靠单一 PR 的日志还不够立得住原案例做了对照组验证CI 通过的 A5 算子d_io_u_grad/g_io_u_grad/extract_glimpse_v2/roi_align_grad目录结构相同、全部没有op_host/CMakeLists.txt只由顶层新宏注册——本 PR 是其中唯一带遗留文件的。结构差异与故障现象精确对应排除了其他共性原因。结论与三级定界输出案例的最终结论不是安装 xml 配置问题用户最初的猜测根因是 CMake 新旧宏注册冲突修复方案只需一行改动——删除objdetect/roi_align/op_host/CMakeLists.txt让新宏全权接管。在技能的三级定界体系代码/工程/环境 → 该谁修中本案例归代码问题 / pkg_install_failclassification_rules.md 中将其明确列为PR 变更导致提交者修并特别注明这类构建成功但 .run 安装自检失败应归代码问题而非环境/平台。原案例给出的定界输出示例三级定界 排除项格式与 report_template.md 的报告模板一致如下## 定界结论 - 失败类型: 代码问题 / 包安装卸载验证失败pkg_install_fail - 根因: PR 新增顶层新宏 add_all_modules_sources(TILING_DIR arch35) 但遗留 op_host/CMakeLists.txt 的旧宏 add_modules_sources 先执行并 将 roi_align 标记已编译already compiled roi_align, skip tiling 源未编译 → cust_opmaster target 未生成 → 库未入包 - 影响 Job: 4 个 A5 编译矩阵x86/arm × 默认/ubuntu24根因组 #1同因 - 处置建议: 通知 PR 提交者删除 objdetect/roi_align/op_host/CMakeLists.txt - 排除项: - 非环境问题: ccache miss0无重编压力、其余 46 job 同机通过 - 非工程问题: 同 workflow 其他 PR 运行正常、依赖下载步骤 COMPLETED注意影响 Job一栏4 个 A5 job 虽然各自 FAILED但错误模式/算子相同按技能的根因聚合原则归入同一根因组 #1报告只展开一次。定界结论中处置出口该联系谁可对照 基础设施支撑矩阵 落位。方法论沉淀从单个案例到可复用判据原案例最后总结了 8 条方法论全部被技能体系吸收为通用判据这里逐条对应说明ASSERT FAILED/execute pkg error是收尾信号generic真正根因在其上方的 [ERROR] 段——对应模式库末尾回溯跳过信号表见到ASSERT FAILED: Build repo、execute pkg error、N FAILED TEST、gmake *** Error 2make 级联、ls: cannot access build_out/后置检查一律跳过继续向前回溯到第一个具体错误文件:行号/算子名/缺失库名才停。构建成功安装失败组合 → 直接跳到包清单比对别在编译错误上浪费时间——这正是流程C包安装失败专项的起手式日志定位[ops_custom] ERROR→ 包清单确认缺失库 → 仓库 cmake 分析打包条件if TARGET X→ target 生成链反查 → cmake 消息佐证 → 对照通过案例定界。already compiled X, skip出现 产物缺失 注册冲突类根因是所有 cmake 语义消息中价值最高的信号之一同族信号还有dont need add tiling sources、skipped, not in ascend_op_name list等均收录于 log_patterns.md §2。目标缺失反查法日志搜Built target X无果 → 查 target 创建条件cmake/symbol.cmake→ 查跳过消息三步定位谁把 target 吞了。对照组方法找同仓库结构相同且 CI 通过的算子比目录/宏用法差异——本案例第 6 步即其应用。只有特定芯片矩阵挂本例仅 A5→ 优先查该芯片专属路径soc 筛选/专属宏这是 L2 层收窄范围的核心判据。多 Job 同因聚合4 个 A5 job 归入同一根因组报告只展开一次同时坚持全部分析不要只报第一个。排除项用数据说话miss0、其余 46 job 同机通过、依赖下载步骤 COMPLETED——每条排除项都挂可验证证据定界结论才立得住。report_template.md 中还给出了 Failed_Reason 的好坏对照好格式是[编译错误]: objdetect/roi_align/op_host/arch35/roi_align_tiling.cpp 编译被跳过already compiled roi_align, skip导致 libcust_opmaster_rt2.0.so 未入包坏格式是只写[ERROR] UT build/test failed这类汇总行。技能体系上下文案例如何被沉淀与复用本案例文件本身是 pipeline-layered-localizer 技能的 references 之一该目录由 .agent/README.md 统一说明将门禁 CI 看护方法论沉淀为可复用 AI 技能供 CannBot 及各代理按需加载也供开发者作为排障手册查阅。在技能的已验证案例清单中本案例与慢 run 案例ops-transformer PR 11316并列标注为ops-cv PR 1310 run#1134 包安装失败 代码问题PR 构建配置 CMake 新旧宏注册冲突致 opmaster 缺库 关键证据already compiled skip 包清单缺 .so排除项ccache miss0、其余 46 job 通过 → 非环境/工程问题支撑该案例定位流程的关键设施还包括只读 API 取数v5 端点查 PR 详情/评论/改动文件v8 端点查 runs/jobs 并download_log下载失败 job 的日志 zipzip 内按步骤分文件首要分析3_compile_acc.log只有 FAILED job 有日志归档端点细节与已知坑见 api_endpoints.md三级定界判据库代码→工程→环境按序首次命中生效pkg_install_fail小类及其配套反查链完整定义于 classification_rules.md日志特征模式库失败锚点、cmake 语义消息、ccache 统计、包清单比对的正则与判读规则集中于 log_patterns.md文末还附了一段解包日志、提取失败锚点/缓存统计/Built target 时间线的 Python 示例代码。技能判据与社区文档同源L0 判据/compile命令、标签语义源自 robot使用指南L2~L4 判据检查项分类、任务状态源自 CI工程检查项概览定界后的处置出口该联系谁指向 基础设施支撑矩阵。实操清单遇到构建成功安装失败时的标准动作综合原案例与方法论可提炼为一份可执行清单适用前提GitCode Actions 上 cann 组织 ops 仓库的 PR 门禁日志结构为3_compile_acc.log类下钻到正确日志以最后一次 run 为准下 identifier 带_0的内层 job 日志而非外层 sub_pipeline job末尾回溯从日志末尾往前找跳过ASSERT FAILED、execute pkg error、Error 2级联等汇总/连锁信号停在第一个具体错误行缺库坐实用 CPack 包清单./packages/...行确认安装器报缺的库确实不在包里避免误判安装器校验逻辑目标缺失反查搜Built target 对应 target无果则查该 target 的创建条件与跳过消息重点识别already compiled X, skipPR 改动面关联拉 PR files diff确认失败算子的 CMakeLists/注册文件是否在改动列表并与同仓库已通过的同类算子对照目录结构与宏用法聚合与排除同因 job 归入一个根因组只报一次定界结论附排除项缓存统计、同机其余 job、依赖下载状态每条挂数据。案例从是不是 xml 没配好的猜测出发最终用一条-- already compiled roi_align, skip日志行加包清单比对完成了定界与定责修复代价仅一行删除。这正是结论必须挂日志原文证据、区分根因与连锁失败两条纪律的完整示范。【免费下载链接】infrastructure本仓库用于托管CANN社区基础设施团队的公开信息包括不限于会议日程成员信息服务文档和配置等信息项目地址: https://gitcode.com/cann/infrastructure创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考