流水线分析报告 — {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编译目标/任务耗时根因组Compile_A5_x86roi_align3.1min#1Compile_A5_armroi_align3.3min#1多 Job 同因 → 同一根因组编号只报一次失败根因分析根因组 #N: {大类} / {小类} — {算子/文件/用例名}判据: {命中的分类判据}影响 Job: {列表}根因证据: {日志原文代码块含文件/行号/算子名}定界结论失败类型:{代码|工程|环境}问题 / {小类}根因: {一句话}处置建议: {该谁修 具体动作}可否重试: {环境问题必填可重试/需人工}排除项:非环境问题: {证据如 ccache miss0、其余 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内层 jobidentifier 带 _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 miss0、其余 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降序取关键路径 jobcompile_acc步骤耗时 ≈ job 总耗时说明时间都花在构建里可下钻到日志层。典型模式arm ≈ 1.8 × x86若同倍率整体变慢则疑似全量重编layer_criteria.md。缓存统计来自日志尾部的 CloudCache JSON。判读规则见 log_patterns.mdmiss/total 50%→ 缓存大面积失效全量/近全量重编慢 run 最常见根因miss ≈ 0 且 remote_hit 高→ 构建本身慢需看时间线。示例 JSON 结构total18652, remote_hit2465, miss16005与配套的 Python 解包提取片段也见该文件。算子/目标级时间线Built target X行自带时间戳[YYYY-MM-DD HH:MM:SS]前缀重建序列后找最大间隔即长尾目标Building CXX object数量等于实际编译 TU 数。根因一句话串起改动 → 缓存失效 → 长尾编译的因果链。实战范本ops-transformer PR 11316 run#5816119.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 miss0非缓存/环境、 其余 46 job 通过非工程/平台处理要点这类失败归代码问题PR 的构建配置错误如 cmake 注册缺失导致产物缺库处置对象是 PR 提交者而非环境/平台。日志特征与处理流程见 log_patterns.md 第 4 节缺失库名 → CPack 包清单确认 → 仓库 cmake 找打包条件如if (TARGET cust_opmaster)→ target 创建链反查 → 结合 cmake 语义消息already compiled/dont need add tiling定位跳过点。常见库语义libcust_opsproto_rt2.0.soproto 定义库、libcust_opmaster_rt2.0.sotiling/ophost 宿主库有 tiling 的算子包必需、libcust_opapi.soL7 opapi 库。实战范本ops-cv PR 1310 run#1134A5 新增 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.soroi_align_tiling.cpp从未编译。铁证是 cmake 消息-- already compiled roi_align, skipPR 在顶层新增新宏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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
流水线分析报告 — {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编译目标/任务耗时根因组Compile_A5_x86roi_align3.1min#1Compile_A5_armroi_align3.3min#1多 Job 同因 → 同一根因组编号只报一次失败根因分析根因组 #N: {大类} / {小类} — {算子/文件/用例名}判据: {命中的分类判据}影响 Job: {列表}根因证据: {日志原文代码块含文件/行号/算子名}定界结论失败类型:{代码|工程|环境}问题 / {小类}根因: {一句话}处置建议: {该谁修 具体动作}可否重试: {环境问题必填可重试/需人工}排除项:非环境问题: {证据如 ccache miss0、其余 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内层 jobidentifier 带 _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 miss0、其余 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降序取关键路径 jobcompile_acc步骤耗时 ≈ job 总耗时说明时间都花在构建里可下钻到日志层。典型模式arm ≈ 1.8 × x86若同倍率整体变慢则疑似全量重编layer_criteria.md。缓存统计来自日志尾部的 CloudCache JSON。判读规则见 log_patterns.mdmiss/total 50%→ 缓存大面积失效全量/近全量重编慢 run 最常见根因miss ≈ 0 且 remote_hit 高→ 构建本身慢需看时间线。示例 JSON 结构total18652, remote_hit2465, miss16005与配套的 Python 解包提取片段也见该文件。算子/目标级时间线Built target X行自带时间戳[YYYY-MM-DD HH:MM:SS]前缀重建序列后找最大间隔即长尾目标Building CXX object数量等于实际编译 TU 数。根因一句话串起改动 → 缓存失效 → 长尾编译的因果链。实战范本ops-transformer PR 11316 run#5816119.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 miss0非缓存/环境、 其余 46 job 通过非工程/平台处理要点这类失败归代码问题PR 的构建配置错误如 cmake 注册缺失导致产物缺库处置对象是 PR 提交者而非环境/平台。日志特征与处理流程见 log_patterns.md 第 4 节缺失库名 → CPack 包清单确认 → 仓库 cmake 找打包条件如if (TARGET cust_opmaster)→ target 创建链反查 → 结合 cmake 语义消息already compiled/dont need add tiling定位跳过点。常见库语义libcust_opsproto_rt2.0.soproto 定义库、libcust_opmaster_rt2.0.sotiling/ophost 宿主库有 tiling 的算子包必需、libcust_opapi.soL7 opapi 库。实战范本ops-cv PR 1310 run#1134A5 新增 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.soroi_align_tiling.cpp从未编译。铁证是 cmake 消息-- already compiled roi_align, skipPR 在顶层新增新宏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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
