流水线分析报告 — {repo} run{num}

流水线分析报告 — {repo} run#{num}

【免费下载链接】infrastructure本仓库用于托管CANN社区基础设施团队的公开信息，包括不限于：会议日程，成员信息，服务文档和配置等信息项目地址: https://gitcode.com/cann/infrastructure

概览

• 状态/工作流/触发事件/分支/PR/触发者/时间区间
• Job 执行统计（COMPLETED x / FAILED y / INIT z）
• 触发链：{作者} /compile 第 {k} 次重试

分层路径

L2 stage: {name} (FAILED, {X}min) L3 job: {job_name} [{identifier}] —— message: {分类结论} L4 step: {step_name} ({X}min, FAILED) L5 日志: {job_id 前8位}.zip → {步骤日志文件}（末尾回溯至根因行）

失败 Job 明细

（多 Job 同因 → 同一根因组编号，只报一次）

失败根因分析

根因组 #N: {大类} / {小类} — {算子/文件/用例名}

• 判据: {命中的分类判据}
• 影响 Job: {列表}
• 根因证据: {日志原文代码块，含文件/行号/算子名}

定界结论

• 失败类型:{代码|工程|环境}问题 / {小类}
• 根因: {一句话}
• 处置建议: {该谁修 + 具体动作}
• 可否重试: {环境问题必填：可重试/需人工}
• 排除项:
  • 非环境问题: {证据，如 "ccache miss=0、其余 46 job 同机通过"}
  • 非工程问题: {证据，如 "同 workflow 其他 PR 运行正常"}

修复建议

{最小改动方案，落到文件级} {需人工确认的点}

### 字段语义与填写要点 - **概览**：记录 run 的基本身份（workflow、触发事件、分支、PR、触发者、时间区间）与 Job 执行统计。统计中的 `INIT` 代表前序失败导致未执行的 stage/job，**不是根因**（见 [layer_criteria.md](https://link.gitcode.com/i/d746e8dd2c52891a5751e20253ac2600) 的 L2 判据）。触发链一行点明重试历史——[SKILL.md](https://link.gitcode.com/i/e5b221bf684e374ae7067babd404eb1e) 强调多次 `/compile` 时**以最后一次运行为准**，前几次作为对照。 - **分层路径**：用 5 行浓缩 L2→L5 的下钻轨迹。分层模型为 `L0 PR → L1 Run → L2 Stage → L3 Job → L4 Step → L5 Log(zip)`，每层都有明确判据信号，完整对照表见 [SKILL.md](https://link.gitcode.com/i/e5b221bf684e374ae7067babd404eb1e)。L3 的 `message` 是初分类的关键：`Sub-pipeline execution failed ... error_details: unknown` 指向加速子流水线基础设施错误（多为重试可恢复）；`步骤compile_acc执行失败，错误信息：点击任务查看详情` 才是真实构建失败、**必须下日志**。注意 `Compile_A5_x86`（外层 job）与 `Compile`（内层 job，identifier 带 `_0`）成对出现，**日志挂在带 `_0` 的内层 job 上**。 - **失败 Job 明细**：表格列出每个失败 Job 及其编译目标、耗时与根因组编号。**多 Job 同因只报一次**——先按错误模式/算子/文件判断是否同根因，归组后用根因组编号（#1 #2 …）串联。 - **失败根因分析**：每个根因组单独一节，必须给出：命中的分类判据（正则或兜底规则）、受影响 Job 列表、以及**日志原文证据**（含文件/行号/算子名/用例名）。判据库见 [classification_rules.md](https://link.gitcode.com/i/10577061a9a54a07acc69ce07f76bc36)，匹配机制为"首次命中生效"，generic 类（如 `UT build/test failed`）只是汇总、仅兜底，fallback_only 类（如 `DEV-CODECI-*`）只是结果、回溯时跳过。 - **定界结论**：三级定界输出"什么类型 + 该谁修"。三大类的处置方向固定：**代码问题**→通知 PR 提交者修复；**工程问题**→转 CI 维护者；**环境问题**→标注可否重试（平台/网络类可重试，磁盘/设备类需人工介入）。完整表见 [SKILL.md](https://link.gitcode.com/i/e5b221bf684e374ae7067babd404eb1e) 的"三级定界"章节。**排除项是定界结论的必备部分**：用证据说明为何不是其他类别，写法示例见 [classification_rules.md](https://link.gitcode.com/i/10577061a9a54a07acc69ce07f76bc36)（如"非环境问题：ccache miss=0、其余 46 job 同机通过"）。 - **修复建议**：给到文件/行级的最小改动方案，并明确标注哪些点需人工确认。 ## 流程B：慢 run 报告追加段 当 run 状态为 `COMPLETED` 但耗时远超仓库基线（[layer_criteria.md](https://link.gitcode.com/i/d746e8dd2c52891a5751e20253ac2600) 给出的参考基线：ops-transformer ~12min、ops-nn ~16min、ops-math ~16.5min、ops-cv ~11min，超过基线 5 倍即值得分析）时，走耗时定位流程，在流程A报告基础上追加以下段落： ```markdown ## 耗时分解 | 层 | 对象 | 耗时 | 占比 | |----|------|------|------| | stage | compile | 112.0min | 93% | | job | Compile_experimental_950_arm | 112.0min | 关键路径 | | step | compile_acc | 111.2min | 99% | ## 缓存统计 - total={N} remote_hit={H} miss={M}（miss率 {P}%） - 判读：{全量重编 / 命中但构建慢 / ...} ## 算子/目标级时间线 | 完成时间 | target | 间隔 | |---------|--------|------| | ... | ... | ... | ## 根因 {如：44 头文件变更 → ccache key 失效 → 长尾算子 kernel 实例化}

数据来源与判读

• 耗时分解：同 stage 内 jobs 按exec_min降序取关键路径 job；compile_acc步骤耗时 ≈ job 总耗时说明时间都花在构建里，可下钻到日志层。典型模式arm ≈ 1.8 × x86，若同倍率整体变慢则疑似全量重编（layer_criteria.md）。
• 缓存统计：来自日志尾部的 CloudCache JSON。判读规则见 log_patterns.md：miss/total > 50%→ 缓存大面积失效（全量/近全量重编，慢 run 最常见根因）；miss ≈ 0 且 remote_hit 高→ 构建本身慢，需看时间线。示例 JSON 结构（total=18652, remote_hit=2465, miss=16005）与配套的 Python 解包提取片段也见该文件。
• 算子/目标级时间线：Built target <X>行自带时间戳（[YYYY-MM-DD HH:MM:SS]前缀），重建序列后找最大间隔即长尾目标；Building CXX object数量等于实际编译 TU 数。
• 根因：一句话串起"改动 → 缓存失效 → 长尾编译"的因果链。

实战范本：ops-transformer PR 11316 run#5816（119.9min，基线 10.4 倍）：44 个头文件变更使 ccache key 全部失效，miss 率 86%，flash_attention_score_grad_apt_ascend950_2单 target 耗时 73min 成为长尾；历史对照（该 job 近 500 次运行 1.1~1.5min）证明这是该系列改动的必然全量重编而非流水线退化。该案例沉淀的方法论：慢 run ≠ 流水线故障，先查 miss 统计排除缓存失效；Built target 时间戳是算子级时间线的唯一可靠来源。

流程C：包安装失败报告追加段

"构建成功但.run安装自检失败"是特殊边界情形，走包安装失败流程，在报告中追加：

## 安装自检失败 - 缺失库：{libX.so} - 包内实际：{存在的库列表} - 打包条件：{cmake 中的 if (TARGET X) 等} ## target 生成链反查 {X 由谁创建} → {跳过点：already compiled / 条件宏} → {根因} ## 对照组 {同仓库通过算子的结构差异} 定界：代码问题（PR 构建配置错误）；排除项：ccache miss=0（非缓存/环境）、 其余 46 job 通过（非工程/平台）

处理要点

这类失败归代码问题（PR 的构建配置错误，如 cmake 注册缺失导致产物缺库），处置对象是 PR 提交者而非环境/平台。日志特征与处理流程见 log_patterns.md 第 4 节：缺失库名 → CPack 包清单确认 → 仓库 cmake 找打包条件（如if (TARGET cust_opmaster)）→ target 创建链反查 → 结合 cmake 语义消息（already compiled/don't need add tiling）定位跳过点。常见库语义：libcust_opsproto_rt2.0.so（proto 定义库）、libcust_opmaster_rt2.0.so（tiling/ophost 宿主库，有 tiling 的算子包必需）、libcust_opapi.so（L7 opapi 库）。

实战范本：ops-cv PR 1310 run#1134：A5 新增 ROIAlign 算子，4 个 A5 编译矩阵全挂而其余 46 job 通过。日志证据链完整展示报告写法——构建与打包实际成功（Self-extractable archive ... successfully created、ccachemiss: 0），失败点仅在.run安装自检（[ops_custom] [ERROR] Required shared library 'libcust_opmaster_rt2.0.so' was not found），包清单只有libcust_opsproto_rt2.0.so，roi_align_tiling.cpp从未编译。铁证是 cmake 消息-- already compiled roi_align, skip：PR 在顶层新增新宏add_all_modules_sources(... TILING_DIR arch35 ...)，但遗留的op_host/CMakeLists.txt旧宏add_modules_sources先执行、tiling glob 不覆盖 arch35 子目录、把 roi_align 标记进 COMPILED_OPS，新宏被去重跳过 → tiling 源永不编译 → 无cust_opmastertarget → 库不入包。对照组（CI 通过的同类 A5 算子均无op_host/CMakeLists.txt）印证是 PR 独有的遗留文件。修复建议一行改动：删除objdetect/roi_align/op_host/CMakeLists.txt。

Failed_Reason 好坏对照

Failed_Reason 是报告中最容易被"读"的字段，模板给出了严格的好/坏对照：

好（引用日志原文 + 技术细节）：

[编译错误]: objdetect/roi_align/op_host/arch35/roi_align_tiling.cpp 编译被跳过 （already compiled roi_align, skip），导致 libcust_opmaster_rt2.0.so 未入包 [LLT测试失败]: UT_AuthService_testLogin testLogin_001 用例失败, expected:<true> but was:<false> [编译错误]: src/ops/gnn.cpp:142:5: error: 'kGiouCoeff' was not declared in this scope

坏（总结行，等于让人再翻日志）：

[ERROR] UT build/test failed ← 汇总不是根因 构建失败 ← 无任何细节 ASSERT FAILED: Build ops-cv ← 平台收尾信号

【免费下载链接】infrastructure本仓库用于托管CANN社区基础设施团队的公开信息，包括不限于：会议日程，成员信息，服务文档和配置等信息项目地址: https://gitcode.com/cann/infrastructure