本项目为开发者提供故障定位工具,包含故障信息收集,软硬件信息展示,AI core error报错分析等能力,提升故障问题定位效率,文档可在昇腾社区搜索“故障处理简介”(选择社区版)。
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix: gitcode-pr skill 回复行内评论改走 v5 discussions 接口 Co-authored-by: sinat_31531339<yuanyue23@huawei.com> # message auto-generated for no-merge-commit merge: !464 merge fix/gitcode-pr-skill-v5-inline-reply into master fix: gitcode-pr skill 回复行内评论改走 v5 discussions 接口 Created-by: sinat_31531339 Commit-by: sinat_31531339 Merged-by: cann-robot Description: ## 描述 两部分改动,都是把实测结论固化进 gitcode-pr skill,避免后续重复踩同一个坑: 1. **reply-review 迁到 v5 接口**:GitCode 已禁用 /api/v4 **写接口**(POST 返回 403,body 当前 /api/v4 接口已禁用,请使用官方文档中的 /api/v5 接口;**读接口 GET 仍返回 200**,见下方「三」的复测更正),该子命令(回复评审意见到对应线程)随之失效。 2. **补入两条编写文档时的强制约定**:中英文档同步、锚点按 GitCode 规则生成。后者源于本次实测发现本仓 README 里十余处锚点在 GitCode 上全部点不动。 ## 一、reply-review 迁到 v5 **实测验证**(PR #443 上真实调用,测试评论已删除): - POST /api/v5/repos/{owner}/{repo}/pulls/{pr}/discussions/{discussion_id}/comments → HTTP 201。 - 对 diff_comment(行内)与 pr_comment(总结)**两类评论都能挂进对应线程**:回查 discussion_id 均与目标一致;回复行内评论时 comment_type=DiffNote。 - 脚本端到端验证:{"posted": true, "note_id": 182796778, "comment_type": "DiffNote", "in_thread": true},再用 delete-comment 清理成功(200 → 404)。 **scripts/pr_ops.py** - cmd_reply_review:由 v4 merge_requests/<pr>/discussions/<id>/notes 改为 v5 pulls/<pr>/discussions/<id>/comments(复用既有 v5_post 助手,不再手写 requests 调用)。 - **修一个取值 bug**:该接口响应中 id 是 **discussion_id(hex 字符串)**、note_id 是**数字评论 id**,而回查与删除端点 /pulls/comments/<X> 只认数字 note_id(传 hex 报 400 note_id, number required)。原代码取 note.get("id") 拿到 hex,导致回查必然失败、in_thread 恒为 null;现改取 note_id。 - 输出新增 comment_type 字段,便于确认回复落点类型。 **SKILL.md** - 能力速查表补入此前缺失的 reply-review 行;review 标注「当前不可用(依赖已禁用的 v4)」。 - **更正旧结论**:原文称 pr_comment 类型「无法线程回复/挂不上线程」,实测两类均可挂,已改写;同时说明总结类评审仍推荐 reply 引用回复——因其为「一条评论回应整轮多条意见」,引用块能保留逐条对应关系。 - 5.3 节改写为 v5 接口,补充上述 id / note_id 语义差异。 - 5.2 节说明**新发起**行内评论目前无可用接口(v4 已禁用;v5 发评论虽接受 path/line 却静默忽略、落成普通评论),替代做法是用 reply 发普通评论并在正文注明 文件:行号。 - trigger 节说明 v4 分支恒 403、实际生效路径恒为 v5。 ## 二、文档编写约定(「提交前本地检查」新增两条) **改动文档必须中英文同步**:本仓文档成对维护(README.md↔README_en.md、examples/README.md↔examples/README_en.md、docs/zh/**↔docs/en/** 等七对)。附可直接执行的检查命令,按**整个 PR 范围**(已提交 + 暂存 + 工作区)判断,避免把「已提交在前一个 commit 里的那一版」误报为未同步。 **锚点须同时满足两个判定方**:GitCode 渲染器(决定网页能否跳转)与流水线 StaticCheck_link_validity(决定门禁)。二者对**含 emoji** 和**含 / ** 的标题给出的 slug 不同,这两类标题没有两边皆可的写法: | 标题形态 | GitCode 渲染 | 流水线期望 | | | --- | --- | --- | --- | | ## 🔧 源码编译 | #源码编译 | #-源码编译 | ⚠️ 冲突 | | ## asys(故障信息收集 / 诊断) | #asys故障信息收集-诊断 | #asys故障信息收集--诊断 | ⚠️ 冲突 | | ### 安装(纯文字) | #安装 | 同 | ✅ 一致 | | ## msprof(性能调优)(有括号无 emoji 无 /) | #msprof性能调优 | 同 | ✅ 一致 | 依据是门禁产物 link_validity_check.csv 的逐条对照:README.md 第 147–149 行同时含 #源码编译 与 #安装,**只有前者被拒**。 写入 skill 的处理方式(按标题形态分三类,均为正向动作): 1. 纯文字或仅含括号的标题 → 直接写锚点。 2. 含 / → 分隔符改「与」/and,标题即脱离冲突形态,深链照常写。 3. 含 emoji(本仓 README*.md 的 h2 全部如此)→ **保留 h2 的 emoji 不动,在其下按内容拆出无 emoji 的 h3,锚点指向 h3**。既不动仓库既有观感,又让链接精确落到子章节而非笼统指向大节。 并给出自查命令(CSV 公开、无需 token): bash curl -sL "https://ascend-ci.obs.cn-north-4.myhuaweicloud.com/<repo>/package/<PR>/link_validity_check.csv" > 该约定已在 #443 实地应用:源码编译 拆出「加载环境变量 / 执行编译 / 编译参数与依赖说明」,安装与验证 沿用既有「安装 / 验证」,锚点分别落到语义最贴近的 h3 上。 ## 三、处理 @newstarzj 检视意见(7 条,commit 8ddac3d) 7 条全部处理,逐条已在对应行内线程回复(in_thread=true)。 | # | 意见 | 处理 | | --- | --- | --- | | 1 | note_id 缺失时 in_thread 静默为 None、仍报 posted:true | 采纳:输出增加 warn 字段 + 实际响应 keys | | 2 | detail=str(data)[:200] 对 dict 截断丢字段 | 采纳:改 detail=data,由 main 统一 JSON 序列化 | | 3 | cmd_review 必然 403 却无友好提示 | 采纳问题、改了实现:把 403 映射为 V4_DISABLED_HINT,而非开头硬 fail | | 4 | 回查失败无诊断信息 | 采纳:并入同一套 warn(附 HTTP 码) | | 5 | v5 新路径无测试覆盖 | 采纳:新增 scripts/test_pr_ops.py(5 例) | | 6 | trigger 先试 v4 属冗余往返 | 采纳:直走 v5,删除孤儿 v4_post_note,via 恒 "v5" | | 7 | 5.1 缺少 pr_comment 选型判据 | 采纳:补判据表(一对一走线程回复,一对多走引用回复) | **第 3 条为何不按建议在开头 fail**:那会让下方实现全部不可达(死代码,且 fetch_diff_refs 随之成孤儿),并把「永久不可用」硬编码进代码——而 v4 禁用是**服务端状态**,几周前尚可用。映射 403 效果等价(调用者同样拿到替代指引),却保留了 position 拼装这块实测知识,v4 写接口若恢复本命令即自愈。 **一处事实更正**(原描述与 SKILL.md 都不准确):不是「任何 v4 请求返回 403」。实测: GET /api/v4/projects/cann%2Foam-tools/merge_requests/464 → 200(完整 PR JSON) POST /api/v4/.../merge_requests/464/discussions → 403 当前 /api/v4 接口已禁用 POST /api/v4/.../merge_requests/464/notes → 403 同上 即**仅写接口(POST)被禁用**。第 3、6 条都以「v4 不可用」为前提,故先验前提再动手;写接口部分成立,两条均采纳,同时把 SKILL.md 内「v4 全废」类表述统一更正为「**写接口**禁用、读仍可用」。 **新增测试**(.claude/ 不在云端 UT_Test 范围——run_tests.sh 只跑 asys/msaicerr/msprof,故定位为改 pr_ops.py 后手动跑的回归测试,命令已写进 SKILL.md): bash python3 -m pytest .claude/skills/gitcode-pr/scripts/test_pr_ops.py -q # 5 passed 覆盖 reply-review 落点判定(正常 / 缺 note_id / 回查失败)、POST 失败时 detail 结构保留、v4 403→指引映射。 **顺带清掉 markdownlint WARNING**:首轮 20 个任务全 SUCCESS、仅 StaticCheck_markdownlint 为 WARNING(不阻断)。取其公开产物 markdownlint.csv 后修掉归属本 PR 的 5 条:MD028(新增引用块与既有引用块相邻产生空行,合并为一个引用块)、MD032(本 PR 改写的列表前补空行)、MD051×3(正文中**示例性**锚点 [源码编译](#执行编译) 被当成真链接,改为行内代码)。该文件内 3 处 MD028、17 处 MD032 属存量、非本 PR 触碰,按仓规未动——CSV 只报了改动区域的那几条,也印证 markdownlint 按增量范围扫描。真正管锚点的 StaticCheck_link_validity 首轮即 SUCCESS。第二轮流水线 20/20 SUCCESS、WARNING 清零。 **本轮真实验证**:7 条回复均经改动后的 reply-review 发出且 in_thread=true;本次 trigger 返回 via: "v5",即第 6 条改动在线上生效。 ## 变更类型 请选择本次引入的变更类型(勾选对应项): - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [ ] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 如何测试 在真实 PR 上验证 reply-review(会产生一条评论,测完删除): bash echo "连通性测试" > /tmp/t.md python3 .claude/skills/gitcode-pr/scripts/pr_ops.py reply-review \ --pr <PR> --owner cann --repo oam-tools \ --discussion-id <某条 diff_comment 的 discussion_id> --body-file /tmp/t.md # 期望 in_thread=true、comment_type=DiffNote;再用返回的数字 note_id 清理: python3 .claude/skills/gitcode-pr/scripts/pr_ops.py delete-comment \ --owner cann --repo oam-tools --comment-id <note_id> 静态检查与回归: - python3 -m ruff check .claude/skills/gitcode-pr/scripts/pr_ops.py → All checks passed。 - python3 -m py_compile 通过;pre-commit(OAT / codespell)全过。 - 本地全量 UT:python3 -m pytest test/ut/asys/ test/ut/msaicerr/ -q → 1123 passed。其中 test_compile_op_ascend950.py::test_get_ub_size_not_tbe 为**存量失败**,在未含本改动的干净工作区复跑同样失败,与本 PR 无关(本 PR 不触碰 msaicerr 代码)。msprof gtest 需编译,本地未覆盖,依赖云端 UT_Test。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md) ## 其他信息 本 PR 仅改动 .claude/skills/gitcode-pr/ 下的 skill 定义与脚本,不涉及产品代码与打包内容。 See merge request: cann/oam-tools!464 | 16 天前 | |
oam-tools切换CCE集群 Co-authored-by: wangchuang616<wangchuang12@huawei.com> # message auto-generated for no-merge-commit merge: !507 merge master into master oam-tools切换CCE集群 Created-by: wangchuang616 Commit-by: wangchuang616 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!507 | 8 天前 | |
【docs】新增工具资料 Co-authored-by: lwx1255555<liuxiaofang17@huawei-partners.com> # message auto-generated for no-merge-commit merge: !318 merge master into master 【docs】新增工具资料 Created-by: lwx1255555 Commit-by: lwx1255555 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> 新增工具资料 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> 已经自检 ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> 新增docs/zh下的工具资料 ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [x] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!318 | 2 个月前 | |
fix: 升级cann-cmake至master-049,适配gcc-15/gcc-16 Co-authored-by: chenhuan1061620<chenhuan65@h-partners.com> # message auto-generated for no-merge-commit merge: !510 merge master into master fix: 升级cann-cmake至master-049,适配gcc-15/gcc-16 Created-by: chenhuan1061620 Commit-by: chenhuan1061620 Merged-by: cann-robot Description: ## 描述 升级 cann-cmake 至 master-049,获取 abseil-cpp GCC 15/16 兼容补丁,配合 gcc-15/gcc-16 适配需求。 ## 变更类型 - [x] 📦 构建过程或辅助工具的变动 ## 变更内容 - cmake/fetch_cann_cmake.cmake: CANN_CMAKE_TAG master-037 → master-049,更新 sha256 - docs/zh/quick_install.md / docs/en/quick_install.md: 依赖表版本号 master-002 → master-049 ## 如何测试 1. CC=gcc-15 CXX=g++-15 bash build.sh --make_clean 编译通过 2. CC=gcc-16 CXX=g++-16 bash build.sh --make_clean 编译通过 3. bash build.sh -u UT 验证,gcc-15 与 gcc-13 结果一致 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(fix:) See merge request: cann/oam-tools!510 | 2 天前 | |
fix: 升级cann-cmake至master-049,适配gcc-15/gcc-16 Co-authored-by: chenhuan1061620<chenhuan65@h-partners.com> # message auto-generated for no-merge-commit merge: !510 merge master into master fix: 升级cann-cmake至master-049,适配gcc-15/gcc-16 Created-by: chenhuan1061620 Commit-by: chenhuan1061620 Merged-by: cann-robot Description: ## 描述 升级 cann-cmake 至 master-049,获取 abseil-cpp GCC 15/16 兼容补丁,配合 gcc-15/gcc-16 适配需求。 ## 变更类型 - [x] 📦 构建过程或辅助工具的变动 ## 变更内容 - cmake/fetch_cann_cmake.cmake: CANN_CMAKE_TAG master-037 → master-049,更新 sha256 - docs/zh/quick_install.md / docs/en/quick_install.md: 依赖表版本号 master-002 → master-049 ## 如何测试 1. CC=gcc-15 CXX=g++-15 bash build.sh --make_clean 编译通过 2. CC=gcc-16 CXX=g++-16 bash build.sh --make_clean 编译通过 3. bash build.sh -u UT 验证,gcc-15 与 gcc-13 结果一致 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(fix:) See merge request: cann/oam-tools!510 | 2 天前 | |
docs: 优化 README 结构,功能示例合并至 examples(#168) Co-authored-by: sinat_31531339<yuanyue23@huawei.com> # message auto-generated for no-merge-commit merge: !443 merge docs/issue-168-readme into master docs: 优化 README 结构,功能示例合并至 examples(#168) Created-by: sinat_31531339 Commit-by: sinat_31531339 Merged-by: cann-robot Description: ## 描述 优化 OAM-Tools 文档结构,落实 issue #168 的三项改进,并保持**中英文档同步**: 1. **功能示例合并至 examples**:将根 README.md 的「功能运行示例」章节(asys / msaicerr / msprof 的环境准备与命令示例)迁移至 examples/README.md,根 README 仅保留一句话导引指向 examples。 2. **重构 examples/README.md**:新增目录导航;章节结构调整为「环境准备 → 一键运行脚本 → 各组件命令示例」;将原先抽象的「样例/说明」表格升级为指向仓内真实脚本(asys/run.sh、msaicerr/run.sh、msprof/run.sh、deploy.sh)的可点击链接,并修正描述与脚本实际行为的对应关系。 3. **删除「相关文档」章节,链接并入核心特性表格**:「核心特性」表格新增「文档」列,四个组件分别指向**仓内**文档(docs/zh/{asys,msaicerr,profiling,hccl_test}/README.md),替换原先的 hiascend.com 外链;删除整个「📚 相关文档」章节,其中唯一不重复的「快速安装指南」「环境变量参考」并入「相关信息」章节以免丢失链接。 4. **英文文档同步(本仓文档成对维护)**:README_en.md 按上述同一结构调整(核心特性表格新增 Documentation / Examples 两列、删除 ▶️ Usage Examples 与 📚 Related Documentation 章节、Quick Start 精简为一句导引、其余链接并入 Related Information);新增 examples/README_en.md 作为 examples/README.md 的英文版。组件用户指南目前仅有中文(docs/zh/),英文版链接指向中文文档并加说明,避免死链。 5. **快速开始恢复为可执行步骤**:原实现把「快速开始」压缩成一句导航句(「请先参考 X,随后按 Y,再参考 Z」),读者读完仍不知该敲什么命令、且要跳三个章节。按业界惯例(快速开始 = 从零到跑通的最短路径,而非导航目录)恢复为 4 步可复制命令:安装依赖 → 编译 → 安装 → 验证,并补一个可验证终点(asys -h)。参数穷举、离线编译、调试构建等仍留在「编译参数与依赖说明」,与快速开始分工。 6. **锚点落到无 emoji 的 h3 子标题**:源码编译 原为一整段无子标题,按内容拆为「加载环境变量 / 执行编译 / 编译参数与依赖说明」;安装与验证 沿用既有「安装 / 验证」。h2 的 emoji 全部保留不动,锚点一律指向这些 h3,且指向语义最贴近的子节(正文「按[源码编译](#执行编译)构建」落在「执行编译」,「[安装](#安装)与[验证](#验证)」分别落在两个子节)。原因见下方「锚点冲突」一节。 ## 锚点冲突(本 PR 曾因此 FAILED 两轮) 本仓锚点要同时满足两个判定方,二者对**含 emoji** 与**含 / ** 的标题给出的 slug 不同,这两类标题没有两边皆可的写法: | 标题形态 | GitCode 渲染(决定网页能否跳转) | 流水线 StaticCheck_link_validity(决定门禁) | | | --- | --- | --- | --- | | ## 🔧 源码编译 | #源码编译 | #-源码编译 | ⚠️ 冲突 | | ## asys(故障信息收集 / 诊断) | #asys故障信息收集-诊断 | #asys故障信息收集--诊断 | ⚠️ 冲突 | | ### 安装(纯文字) | #安装 | 同 | ✅ 一致 | | ## msprof(性能调优)(有括号无 emoji 无 /) | #msprof性能调优 | 同 | ✅ 一致 | 依据是门禁产物 link_validity_check.csv 的逐条对照:README.md 第 147–149 行同时含 #源码编译 与 #安装,**只有前者被拒**。 故本 PR 让锚点只落在「两边一致」的标题上:h2 保留 emoji 但不作锚点目标,其下拆出无 emoji 的 h3 承接锚点;asys 标题的 / 改为「与」后即可正常深链,因此核心特性表「运行示例」列三个组件保持统一的深链风格。该约定已写入仓内 gitcode-pr skill(另提 PR #464)。 ## 评审意见处理 - **@jinyingqi(major,已采纳)**:examples/README.md 中 9 处 ${ASCEND_INSTALL_PATH} 统一改为 ${ASCEND_HOME_PATH}。核实依据:build.sh:79 为 ASCEND_INSTALL_PATH="${ASCEND_HOME_PATH}",该变量由 build.sh 自行派生而非 set_env.sh 导出;examples/msaicerr/run.sh:19、examples/msprof/run.sh:19 亦用 ${ASCEND_INSTALL_PATH:-${ASCEND_HOME_PATH:-...}} 兜底,反证其不保证存在。英文版同步采用 ${ASCEND_HOME_PATH}。 - **@newstarzj**:四条意见已逐条核实并回复。其中「脚本未创建」经核实不成立(四个脚本由 ee4b95c 早已合入 master,属仓内既有文件,故不在本 PR diff 中);两条锚点死链不成立(README.md 存在 ## 📦 安装与验证,#-安装与验证 为其 emoji 剥离后的锚点,同写法在 master 已广泛使用);「保留 hiascend 外链」与 issue #168 第 3 条「链接指向仓内的组件文档」的验收要求冲突,已说明理由待评审确认。 ## 变更类型 请选择本次引入的变更类型(勾选对应项): - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [ ] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue 关联 Issue #168 ## 如何测试 - 校验所有仓内文档链接目标存在:docs/zh/{asys,msaicerr,profiling,hccl_test}/README.md、docs/en/quick_install.md、examples/README_en.md、CONTRIBUTING_en.md、SECURITY_en.md 均存在。 - 校验 examples/README.md / examples/README_en.md 中相对链接(asys/run.sh、msaicerr/run.sh、msprof/run.sh、deploy.sh、../docs/zh/...、../README.md / ../README_en.md)均可解析。 - 校验中英锚点各自自洽:中文 #-源码编译、#-安装与验证;英文 #-source-code-compilation、#-installation-and-verification,以及 examples 英文版三个组件锚点。 - 确认根 README 与 README_en 均已无「相关文档」/「Related Documentation」章节,章节结构完整无断链。 - 本地全量 UT:python3 -m pytest test/ut/asys/ test/ut/msaicerr/ -q → 1104 passed(test_compile_op_ascend950.py::test_get_ub_size_not_tbe 为存量失败,在未含本 PR 改动的干净工作区复跑同样失败,与本次纯文档改动无关)。msprof gtest 需编译,本地未覆盖,依赖云端 UT_Test。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md) ## 其他信息 本次为纯文档改动,涉及 README.md、README_en.md、examples/README.md 与新增 examples/README_en.md 四个文件,不含代码逻辑变更。 See merge request: cann/oam-tools!443 | 5 天前 | |
experiment(task-book): 新增 msprof 性能采集四种方式实操示例 Co-authored-by: imaginationhh<921918760@qq.com> # message auto-generated for no-merge-commit merge: !279 merge demo-msprof-pr into master experiment(task-book): 新增 msprof 性能采集四种方式实操示例 Created-by: imaginationhh Commit-by: imaginationhh Merged-by: cann-robot Description: ## 描述 新增 msprof 性能采集工具的实操示例,放在 experiment/task-book/msprof_experience_demo/。 用最简 TinyMLP (4 层 Linear+GELU, 输入 [32,1024]) 作统一负载,演示昇腾 NPU 上四种 msprof 采集方式: - **01_cmdline**: msprof 命令行黑盒采集 (零侵入) - **02_api_AscendC**: AscendC 自定义算子核函数直调 + 采集 - **03_api_pyAcl**: pyACL 加载 .om 离线模型推理 + 采集 - **04_pyTorch**: torch_npu.profiler API 白盒插桩采集 四种方式的脚本均可实跑复现;为避免多份数据基准不一致,**性能数据只保留 PyTorch API (04) 一份**作为示例 (perf-data 含 op_statistic / op_summary PMU / step_trace 等可读结果)。每个子目录 README 含「选型指南」「输入输出说明」「如何用到你的模型」。shell 脚本通过 ASCEND_HOME_PATH 自动定位 CANN 环境,不依赖个人机器路径。 ## 关联的Issue 无 ## 测试 四种方式均在 Atlas A2 (910B3) + CANN 9.1.0 + torch_npu 2.7.1 环境实跑验证: - 01/04 采集出 op_statistic (MatMulV2 占比 ~78%) - 02 AscendC Add 算子编译并采集到 AI Core PMU - 03 pyACL 完成 ONNX→ATC→om→推理全链路 - 04 step_trace 显示典型 host bound (Computing:Free ≈ 1:60) ## 文档更新 新增总 README + 4 个子目录 README + perf-data/README,含目录结构、msprof 参数说明、性能数据表。 ## 类型标签 - [x] 📝 文档更新 - [x] ❓ 其他,请描述:新增 task-book 实操示例 (示例代码 + 实采性能数据) See merge request: cann/oam-tools!279 | 2 个月前 | |
docs: correct typo Specific to Specify in help info Co-authored-by: jinyingqi<jinyingqi@huawei.com> # message auto-generated for no-merge-commit merge: !494 merge fix/help-info-typo-blink into master docs: correct typo Specific to Specify in help info Created-by: BlinkRune_92 Commit-by: jinyingqi Merged-by: cann-robot Description: ## 描述 修复 scripts/package/oam_tools/scripts/help.info 中 --check-path 参数说明的拼写错误:将 Specific the path 修正为 Specify the path,与文件内其他参数说明(如 Specify the path of docker root)用词保持一致。 ## 关联的Issue 无 ## 测试 本地执行 bash build.sh --component msprof 构建通过,确认打包产物中的 help.info 已同步更新,纯文案修改,不涉及逻辑变更。 ## 文档更新 无 ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!494 | 11 天前 | |
skills: 新增三个 CANN NPU 性能优化 skill (multistream-optimize / npu-perfanalysis / perf-breakdown) Co-authored-by: imaginationhh<921918760@qq.com> # message auto-generated for no-merge-commit merge: !302 merge add-cann-perf-skills into master skills: 新增三个 CANN NPU 性能优化 skill (multistream-optimize / npu-perfanalysis / perf-breakdown) Created-by: imaginationhh Commit-by: imaginationhh Merged-by: cann-robot Description: ## 新增三个 CANN NPU 性能优化 skill 将三个 NPU 性能相关 skill 引入 skills/,沿用现有 skills/cann-log-analysis 的布局,统一 cann- 命名。 ### 内容 | 目录 | 用途 | 源仓库 | |---|---|---| | skills/cann-multistream-optimize | NPU 多流整网优化(双流 / stream overlap / 控核 / TorchAir 多流) | jinyingqi/multi-stream-skill | | skills/cann-npu-perfanalysis | Ascend NPU profiling 8 维性能诊断(Host/Device Bound、MFU、通信、空泡等) | jinyingqi/npu-perf-analysis | | skills/cann-perf-breakdown | kernel_details.csv 按模型结构层级拆解性能数据 | jinyingqi/perf-breakdown-skill | ### 说明 - 三个 skill 内容取自各自源仓库的未修改版本。 - 各 SKILL.md 的 name 字段与目录名对齐为 cann-xxx。 - cann-perf-breakdown 与 cann-npu-perfanalysis 之间的 sibling 委托引用已同步更新为新名;真实仓库 URL 与 .skills_cache 缓存路径保持不变。 - 共 47 个文件,未引入二进制大文件。 🤖 Generated with [Claude Code](https://claude.com/claude-code) See merge request: cann/oam-tools!302 | 2 个月前 | |
[Profiling]修复--application参数错误把-m识别成路径,命令解析失败问题 Co-authored-by: z296249221<zhengkai40@huawei.com> # message auto-generated for no-merge-commit merge: !512 merge profiling-fix-application into master [Profiling]修复--application参数错误把-m识别成路径,命令解析失败问题 Created-by: z296249221 Commit-by: z296249221 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> 问题:使用msprof --application="python3 -m ais-bench xxxx"场景时,在现有的设计里,会将python3后面的"-m"按appPath拆解成app_dir和app,会因为不支持校验和拆解而报错; 方案: 在用户执行的是python或者sh命令时,直接将python或sh按appPath处理,app_dir设置成当前路径,用于后续设置result_dir,app设置python或sh,用于后续的校验等流程;application.cpp里拼接执行命令时不再传入app_dir和app; application.cpp里删除原app_dir和app的相关处理,直接使用cmdPath参数 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> Issue [#183](https://gitcode.com/cann/oam-tools/issues/183) ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> msprof --application="python3 -m ais-bench xxxx" ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> NA ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!512 | 1 天前 | |
[Profiling]修复--application参数错误把-m识别成路径,命令解析失败问题 Co-authored-by: z296249221<zhengkai40@huawei.com> # message auto-generated for no-merge-commit merge: !512 merge profiling-fix-application into master [Profiling]修复--application参数错误把-m识别成路径,命令解析失败问题 Created-by: z296249221 Commit-by: z296249221 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> 问题:使用msprof --application="python3 -m ais-bench xxxx"场景时,在现有的设计里,会将python3后面的"-m"按appPath拆解成app_dir和app,会因为不支持校验和拆解而报错; 方案: 在用户执行的是python或者sh命令时,直接将python或sh按appPath处理,app_dir设置成当前路径,用于后续设置result_dir,app设置python或sh,用于后续的校验等流程;application.cpp里拼接执行命令时不再传入app_dir和app; application.cpp里删除原app_dir和app的相关处理,直接使用cmdPath参数 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> Issue [#183](https://gitcode.com/cann/oam-tools/issues/183) ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> msprof --application="python3 -m ais-bench xxxx" ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> NA ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!512 | 1 天前 | |
add clang-format Co-authored-by: sinat_31531339<yuanyue23@huawei.com> # message auto-generated for no-merge-commit merge: !146 merge dev_master_format into master add clang-format Created-by: sinat_31531339 Commit-by: sinat_31531339 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> 新增.clang-format ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> 关联Issue #45 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> 不涉及 ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> 新增格式规范文件 ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [x] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!146 | 4 个月前 | |
【docs】新增工具资料 Co-authored-by: lwx1255555<liuxiaofang17@huawei-partners.com> # message auto-generated for no-merge-commit merge: !318 merge master into master 【docs】新增工具资料 Created-by: lwx1255555 Commit-by: lwx1255555 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> 新增工具资料 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> 已经自检 ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> 新增docs/zh下的工具资料 ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [x] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!318 | 2 个月前 | |
adapt oversize dump name Co-authored-by: starchen_<hongwenchen1@huawei.com> # message auto-generated for no-merge-commit merge: !498 merge oversize_dumpname into master adapt oversize dump name Created-by: starchen_ Commit-by: starchen_ Merged-by: cann-robot Description: ## 描述 适配dump落盘文件名超长场景 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> ## 测试 通过UT/ST/RDV测试 新特性自验证通过 ## 文档更新 无 ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!498 | 9 天前 | |
文档优化 Co-authored-by: sinat_31531339<yuanyue23@huawei.com> # message auto-generated for no-merge-commit merge: !213 merge dev_master_fixinstallmd into master 文档优化 Created-by: sinat_31531339 Commit-by: sinat_31531339 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> 1. quick_install.md 添加手动安装方式的说明 2. AGENTS.md中补充SKILL.md 的跳转链接 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> [#79](https://gitcode.com/cann/oam-tools/issues/79) [#77](https://gitcode.com/cann/oam-tools/issues/77) ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> 不涉及 ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> AGENTS.md quick_install.md ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [x] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!213 | 3 个月前 | |
【文档翻译】部分文档翻译成英文。 Co-authored-by: lwx1255555<liuxiaofang17@huawei-partners.com> # message auto-generated for no-merge-commit merge: !238 merge master into master 【文档翻译】部分文档翻译成英文。 Created-by: lwx1255555 Commit-by: lwx1255555 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> md文档翻译成英文 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> 不涉及 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> 已经自检 ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> 更新的文档如下。 .claude/CLAUDE_en.md .claude/skills/default-skills/SKILL_en.md .gitcode/PULL_REQUEST_TEMPLATE.en-US.md .opencode/README_en.md AGENTS_en.md CONTRIBUTING_en.md README_en.md SECURITY_en.md docs/en/quick_install.md src/hccl_test/README_en.md ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [x] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!238 | 3 个月前 | |
build: 回退打包期权限收紧,交回 cmake 默认值 Co-authored-by: sinat_31531339<yuanyue23@huawei.com> # message auto-generated for no-merge-commit merge: !504 merge revert/pkg-perm-555 into master build: 回退打包期权限收紧,交回 cmake 默认值 Created-by: sinat_31531339 Commit-by: sinat_31531339 Merged-by: cann-robot Description: ## 描述 回退打包期对**目录**权限的收紧,交回 cmake 默认的 755;**文件权限保持 555 不变**。 ### 为什么要回退 打包声明把目录权限收紧到 555( r-xr-xr-x)后,落地的目录**没有 owner 写位**。 而 unlink 一个条目要的是**父目录**的写位——父目录缺 u+w 就删不掉里面的内容。 于是 build/_CPack_Packages/ 下的 staging 子树一旦产出,rm -rf build 全程 Permission denied。**这与是不是 root 无关**:目录属主本就是当前用户,属主自己 也删不掉。 直接后果是 **CI 随机失败**:流水线复用工作区,下一轮清理残留 build/ 时删不掉 即报错;而失败与否取决于上一轮是否跑到了产出 555 目录的打包阶段,所以表现为 时好时坏的随机失败,不易复现也不易定位。 权限收紧本身是后续需求要做的整改项(届时需连带解决产物目录的可删除性)。 **当前先做删除处理**,让产物目录恢复可删除,先把 CI 随机失败止住。 ### 为什么只回退目录、不动文件 初版是全量回退(目录 + 文件都交回默认值)。评审(jinyingqi,major)指出:本 PR 要解决的是目录缺 owner 写位,而**文件无写位并不阻塞 rm -rf**,删除只看父目录的 写位;全量回退会让 profiler_tool 文件从 555 退回 644,属超出问题范围的行为回退, 且可能丢失脚本/工具文件的可执行位。 该意见成立,已按其建议收窄。**收窄方案经本地实测确认不影响 build/ 的删除** (见下方"本地实测结果"),故采纳。 ### 改动点 | 位置 | 改动 | 改动后 | |------|------|--------| | CMakeLists.txt built-in 段 | 删除 DIRECTORY_PERMISSIONS ... 555 | 目录 **755**;文件保留显式 **440** | | msprofbin/CMakeLists.txt whl 段 | 保留 install(PROGRAMS) 的 PERMISSIONS 555 | whl **555**(不变) | | msprofbin/CMakeLists.txt 解包段 | 保留 FILE_PERMISSIONS 555,删除 DIRECTORY_PERMISSIONS | 文件 **555**(不变)/ 目录 **755** | 即:**只放开目录的 owner 写位,文件权限一律不动**。这样既修好产物目录的可删除性, 又让 --noexec --extract 旁路(不跑安装脚本)下的文件权限与运行期 msprof_install.sh 的 change_file_mode 555 保持一致。 whl 的解包方式不变(仍是构建期 add_custom_command 解包 + install(DIRECTORY) 声明进包),本 PR 只调整权限声明。 ### 补充事实:安装后的权限不由 cmake 声明决定 评审过程中核实了整条权限链路,一并记录,避免后续误解: XML install_mod → filelist.csv 的 permission 字段 → 安装期 install_common_parser.sh do_chmod_file_dir → change_mod_and_own_* 实测本次构建产物 filelist.csv:tools/profiler/profiler_tool = 750 (来自 oam_tools.xml:107)、opp/built-in/op_impl/ai_core/tbe = 550 (DetectInfo.xml:25)、.../tbe/impl/ops_oam = 555(DetectInfo.xml:17)。 change_mod_and_own_dirs()(common_func_v2.inc:958)只读 csv 的 mod 字段, **完全不看 cmake 的 install() 声明**。 所以本改动**不影响 --full 正常安装后的任何权限**,受影响的只有打包 staging 树与 --noexec --extract 旁路——而 staging 树里的 555 目录正是要修的问题。 ### 用例改动 **新增** test/ut/asys/testcase/common/test_build_dir_removable.py,看护"编译产物 目录在编译后可被删除",5 条用例分两层: | 用例 | 作用 | |------|------| | test_scan_actually_finds_cmake_files | 自检:确认扫描确有产出、顶层 CMakeLists.txt 在范围内 | | test_no_directory_permission_decl_drops_owner_write | 静态看护:任何 DIRECTORY_PERMISSIONS 声明都必须含 OWNER_WRITE | | test_no_cmake_chmod_strips_owner_write | 静态看护:禁止会作用到**目录**的 chmod 摘掉 owner 写位 | | test_dir_without_owner_write_blocks_removal | 机制验证:555 目录下的内容确实无法 rmtree,复现根因 | | test_restoring_owner_write_makes_dir_removable | 机制验证:补回 owner 写位后即可删除 | 第 3 条只查**会作用到目录**的两种写法——递归 chmod -R <mode>、以及 find -type d ... -exec chmod <mode>;纯文件 chmod(chmod 440 file、 find -type f -exec chmod 555)放行,因为文件无写位不影响删除。 **同步修改** test_msprof_whl_package.py:断言文件权限必须显式 555(FILE_PERMISSIONS 与 whl 的 PERMISSIONS),且目录权限**要么不声明、要么必须含 OWNER_WRITE**。 实现上有几点是踩坑与评审后定下来的,一并说明: 1. **仓库根按标记向上搜索,不按固定层级数推算**。初版用 Path(__file__).resolve().parents[5],在云端流水线的工作区布局下算到了不存在 的路径(报"文件地址没有找到")。更隐蔽的是:路径算错时扫不到任何文件、违规 列表恒为空,静态看护会**静默通过**。故改为向上搜索 CMakeLists.txt + build.sh + cmake 三者同时存在的目录;找不到时返回 None、由用例 skip(**不在模块级抛异常**——那会让 pytest 在收集阶段报 ERROR 并中断整个会话)。并新增上表第 1 条自检用例堵住"扫不到→静默通过"。 2. **test_dir_without_owner_write_blocks_removal 在 root 下 skip**。root 有 CAP_DAC_OVERRIDE,绕过权限位检查,555 目录下 rmtree 照样成功,无法复现 普通用户的 PermissionError;而云端 UT 以 root 运行(产物路径 /tmp/pytest-of-root/)。真正的看护由两条静态扫描承担,与运行身份无关。 finally 里恢复写位也补了存在性判断——目录可能已被删掉,直接 chmod 会抛 FileNotFoundError 盖住断言的真实失败原因。 3. **用 Path.chmod 而非调外部 chmod**。chmod 在不同发行版下路径不同 (/bin 或 /usr/bin),写死绝对路径会在部分环境抛 FileNotFoundError。 4. **install(DIRECTORY) 关键字表按 cmake 官方签名补全**,作为权限串的终止边界, 避免跨声明匹配(原来只列了 7 个,遗漏 TYPE/USE_SOURCE_PERMISSIONS/ CONFIGURATIONS/EXCLUDE_FROM_ALL/REGEX/PERMISSIONS 等)。 ## 变更类型 请选择本次引入的变更类型(勾选对应项): - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [ ] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [x] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 如何测试 1. 全量打包: bash bash build.sh -j16 2. **核心判据**——确认产物目录可删除(改动前此处会 Permission denied): bash find build -type d ! -perm -u+w | wc -l # 期望 0 rm -rf build && echo "build removed ok" 3. 核对 staging 树权限(确认文件仍为 555、目录已放开写位): bash S=build/_CPack_Packages/makeself_staging find $S/tools/profiler/profiler_tool -type f -printf '%m\n' | sort | uniq -c # 期望 555 find $S/tools/profiler/profiler_tool -type d -printf '%m\n' | sort | uniq -c # 期望 755 find $S/opp/built-in/op_impl/ai_core/tbe -type d -printf '%m\n' | sort -u # 期望 755 find $S/opp/built-in/op_impl/ai_core/tbe -type f -printf '%m\n' | sort -u # 期望 440 4. UT: bash python3 -m pytest test/ut/asys/testcase/common/test_build_dir_removable.py -v python3 -m pytest test/ut/asys/testcase/common/test_msprof_whl_package.py -v python3 -m pytest test/ut/asys/ test/ut/msaicerr/ -q **本地实测结果**(收窄方案) - bash build.sh -j16 通过(exit=0)。 - **核心判据通过**:find build -type d ! -perm -u+w | wc -l = **0**; rm -rf build **成功**。这是采纳收窄方案的前提条件,已确认满足。 - staging 权限与预期一致:profiler_tool **764 个文件全为 555**、135 个目录 755; tbe 40 个目录 755、84 个文件 440。 - test_build_dir_removable.py 5 passed、test_msprof_whl_package.py 9 passed。 - 静态看护有效性反向验证: | 注入的写法 | 期望 | 实测 | |------------|------|------| | 加回 DIRECTORY_PERMISSIONS ... 555 | 拦截 | ✅ 转红并报出违规位置 | | chmod -R 555 <dir> | 拦截 | ✅ 转红 | | find -type d -exec chmod 555 | 拦截 | ✅ 转红 | | find -type f -exec chmod 555 | 放行 | ✅ 通过 | | chmod 440 some_file | 放行 | ✅ 通过 | | 纯注释行 # chmod -R 555 ... | 忽略 | ✅ 通过 | - 全量 test/ut/asys/ test/ut/msaicerr/:1213 passed / 15 skipped, 另有 1 项 test_compile_op_ascend950.py::test_get_ub_size_not_tbe 失败, 已在干净的 upstream/master worktree 上复现,属**存量失败、与本改动无关**。 - msprof gtest 未在本地跑,依赖云端 UT_Test。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md) ## 其他信息 本 PR 已同步一份到 9.1.0 分支:#505。两分支权限终态一致,但实现写法不同—— 9.1.0 上 whl 处理位于 msprofbin/closed/CMakeLists.txt 且为 install(CODE) + chmod -R 555 形态(master 已重构为构建期 add_custom_command 解包 + install(DIRECTORY)),故那边改为 find -type f -exec chmod 555(只作用文件、 目录保持 pip 解出的 755)来达到同一效果,而非直接 cherry-pick。 See merge request: cann/oam-tools!504 | 9 天前 | |
delete empty conf folders and fix documents Co-authored-by: starchen_<hongwenchen1@huawei.com> # message auto-generated for no-merge-commit merge: !37 merge master into master delete empty conf folders and fix documents Created-by: starchen_ Commit-by: starchen_ Merged-by: cann-robot Description: ## 描述 1.删除run包中的的空文件夹 2.文档更新 ## 关联的Issue 关联Issue [#8](https://gitcode.com/cann/oam-tools-dev/issues/8) 关联Issue [#9](https://gitcode.com/cann/oam-tools-dev/issues/9) ## 测试 UT/ST通过,冒烟无问题 ## 文档更新 更新了README.md和CONTRIBUTING.md文件 ## 类型标签 <!-- [x] 表示选中 --> - [x] Bug修复 - [ ] 新特性 - [ ] 性能优化 - [x] 文档更新 - [ ] 其他,请描述: See merge request: cann/oam-tools!37 | 6 个月前 | |
【文档翻译】部分文档翻译成英文。 Co-authored-by: lwx1255555<liuxiaofang17@huawei-partners.com> # message auto-generated for no-merge-commit merge: !238 merge master into master 【文档翻译】部分文档翻译成英文。 Created-by: lwx1255555 Commit-by: lwx1255555 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> md文档翻译成英文 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> 不涉及 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> 已经自检 ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> 更新的文档如下。 .claude/CLAUDE_en.md .claude/skills/default-skills/SKILL_en.md .gitcode/PULL_REQUEST_TEMPLATE.en-US.md .opencode/README_en.md AGENTS_en.md CONTRIBUTING_en.md README_en.md SECURITY_en.md docs/en/quick_install.md src/hccl_test/README_en.md ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [x] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!238 | 3 个月前 | |
Initial commit | 7 个月前 | |
Initial commit | 7 个月前 | |
docs: 优化 README 结构,功能示例合并至 examples(#168) Co-authored-by: sinat_31531339<yuanyue23@huawei.com> # message auto-generated for no-merge-commit merge: !443 merge docs/issue-168-readme into master docs: 优化 README 结构,功能示例合并至 examples(#168) Created-by: sinat_31531339 Commit-by: sinat_31531339 Merged-by: cann-robot Description: ## 描述 优化 OAM-Tools 文档结构,落实 issue #168 的三项改进,并保持**中英文档同步**: 1. **功能示例合并至 examples**:将根 README.md 的「功能运行示例」章节(asys / msaicerr / msprof 的环境准备与命令示例)迁移至 examples/README.md,根 README 仅保留一句话导引指向 examples。 2. **重构 examples/README.md**:新增目录导航;章节结构调整为「环境准备 → 一键运行脚本 → 各组件命令示例」;将原先抽象的「样例/说明」表格升级为指向仓内真实脚本(asys/run.sh、msaicerr/run.sh、msprof/run.sh、deploy.sh)的可点击链接,并修正描述与脚本实际行为的对应关系。 3. **删除「相关文档」章节,链接并入核心特性表格**:「核心特性」表格新增「文档」列,四个组件分别指向**仓内**文档(docs/zh/{asys,msaicerr,profiling,hccl_test}/README.md),替换原先的 hiascend.com 外链;删除整个「📚 相关文档」章节,其中唯一不重复的「快速安装指南」「环境变量参考」并入「相关信息」章节以免丢失链接。 4. **英文文档同步(本仓文档成对维护)**:README_en.md 按上述同一结构调整(核心特性表格新增 Documentation / Examples 两列、删除 ▶️ Usage Examples 与 📚 Related Documentation 章节、Quick Start 精简为一句导引、其余链接并入 Related Information);新增 examples/README_en.md 作为 examples/README.md 的英文版。组件用户指南目前仅有中文(docs/zh/),英文版链接指向中文文档并加说明,避免死链。 5. **快速开始恢复为可执行步骤**:原实现把「快速开始」压缩成一句导航句(「请先参考 X,随后按 Y,再参考 Z」),读者读完仍不知该敲什么命令、且要跳三个章节。按业界惯例(快速开始 = 从零到跑通的最短路径,而非导航目录)恢复为 4 步可复制命令:安装依赖 → 编译 → 安装 → 验证,并补一个可验证终点(asys -h)。参数穷举、离线编译、调试构建等仍留在「编译参数与依赖说明」,与快速开始分工。 6. **锚点落到无 emoji 的 h3 子标题**:源码编译 原为一整段无子标题,按内容拆为「加载环境变量 / 执行编译 / 编译参数与依赖说明」;安装与验证 沿用既有「安装 / 验证」。h2 的 emoji 全部保留不动,锚点一律指向这些 h3,且指向语义最贴近的子节(正文「按[源码编译](#执行编译)构建」落在「执行编译」,「[安装](#安装)与[验证](#验证)」分别落在两个子节)。原因见下方「锚点冲突」一节。 ## 锚点冲突(本 PR 曾因此 FAILED 两轮) 本仓锚点要同时满足两个判定方,二者对**含 emoji** 与**含 / ** 的标题给出的 slug 不同,这两类标题没有两边皆可的写法: | 标题形态 | GitCode 渲染(决定网页能否跳转) | 流水线 StaticCheck_link_validity(决定门禁) | | | --- | --- | --- | --- | | ## 🔧 源码编译 | #源码编译 | #-源码编译 | ⚠️ 冲突 | | ## asys(故障信息收集 / 诊断) | #asys故障信息收集-诊断 | #asys故障信息收集--诊断 | ⚠️ 冲突 | | ### 安装(纯文字) | #安装 | 同 | ✅ 一致 | | ## msprof(性能调优)(有括号无 emoji 无 /) | #msprof性能调优 | 同 | ✅ 一致 | 依据是门禁产物 link_validity_check.csv 的逐条对照:README.md 第 147–149 行同时含 #源码编译 与 #安装,**只有前者被拒**。 故本 PR 让锚点只落在「两边一致」的标题上:h2 保留 emoji 但不作锚点目标,其下拆出无 emoji 的 h3 承接锚点;asys 标题的 / 改为「与」后即可正常深链,因此核心特性表「运行示例」列三个组件保持统一的深链风格。该约定已写入仓内 gitcode-pr skill(另提 PR #464)。 ## 评审意见处理 - **@jinyingqi(major,已采纳)**:examples/README.md 中 9 处 ${ASCEND_INSTALL_PATH} 统一改为 ${ASCEND_HOME_PATH}。核实依据:build.sh:79 为 ASCEND_INSTALL_PATH="${ASCEND_HOME_PATH}",该变量由 build.sh 自行派生而非 set_env.sh 导出;examples/msaicerr/run.sh:19、examples/msprof/run.sh:19 亦用 ${ASCEND_INSTALL_PATH:-${ASCEND_HOME_PATH:-...}} 兜底,反证其不保证存在。英文版同步采用 ${ASCEND_HOME_PATH}。 - **@newstarzj**:四条意见已逐条核实并回复。其中「脚本未创建」经核实不成立(四个脚本由 ee4b95c 早已合入 master,属仓内既有文件,故不在本 PR diff 中);两条锚点死链不成立(README.md 存在 ## 📦 安装与验证,#-安装与验证 为其 emoji 剥离后的锚点,同写法在 master 已广泛使用);「保留 hiascend 外链」与 issue #168 第 3 条「链接指向仓内的组件文档」的验收要求冲突,已说明理由待评审确认。 ## 变更类型 请选择本次引入的变更类型(勾选对应项): - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [ ] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue 关联 Issue #168 ## 如何测试 - 校验所有仓内文档链接目标存在:docs/zh/{asys,msaicerr,profiling,hccl_test}/README.md、docs/en/quick_install.md、examples/README_en.md、CONTRIBUTING_en.md、SECURITY_en.md 均存在。 - 校验 examples/README.md / examples/README_en.md 中相对链接(asys/run.sh、msaicerr/run.sh、msprof/run.sh、deploy.sh、../docs/zh/...、../README.md / ../README_en.md)均可解析。 - 校验中英锚点各自自洽:中文 #-源码编译、#-安装与验证;英文 #-source-code-compilation、#-installation-and-verification,以及 examples 英文版三个组件锚点。 - 确认根 README 与 README_en 均已无「相关文档」/「Related Documentation」章节,章节结构完整无断链。 - 本地全量 UT:python3 -m pytest test/ut/asys/ test/ut/msaicerr/ -q → 1104 passed(test_compile_op_ascend950.py::test_get_ub_size_not_tbe 为存量失败,在未含本 PR 改动的干净工作区复跑同样失败,与本次纯文档改动无关)。msprof gtest 需编译,本地未覆盖,依赖云端 UT_Test。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md) ## 其他信息 本次为纯文档改动,涉及 README.md、README_en.md、examples/README.md 与新增 examples/README_en.md 四个文件,不含代码逻辑变更。 See merge request: cann/oam-tools!443 | 5 天前 | |
docs: 优化 README 结构,功能示例合并至 examples(#168) Co-authored-by: sinat_31531339<yuanyue23@huawei.com> # message auto-generated for no-merge-commit merge: !443 merge docs/issue-168-readme into master docs: 优化 README 结构,功能示例合并至 examples(#168) Created-by: sinat_31531339 Commit-by: sinat_31531339 Merged-by: cann-robot Description: ## 描述 优化 OAM-Tools 文档结构,落实 issue #168 的三项改进,并保持**中英文档同步**: 1. **功能示例合并至 examples**:将根 README.md 的「功能运行示例」章节(asys / msaicerr / msprof 的环境准备与命令示例)迁移至 examples/README.md,根 README 仅保留一句话导引指向 examples。 2. **重构 examples/README.md**:新增目录导航;章节结构调整为「环境准备 → 一键运行脚本 → 各组件命令示例」;将原先抽象的「样例/说明」表格升级为指向仓内真实脚本(asys/run.sh、msaicerr/run.sh、msprof/run.sh、deploy.sh)的可点击链接,并修正描述与脚本实际行为的对应关系。 3. **删除「相关文档」章节,链接并入核心特性表格**:「核心特性」表格新增「文档」列,四个组件分别指向**仓内**文档(docs/zh/{asys,msaicerr,profiling,hccl_test}/README.md),替换原先的 hiascend.com 外链;删除整个「📚 相关文档」章节,其中唯一不重复的「快速安装指南」「环境变量参考」并入「相关信息」章节以免丢失链接。 4. **英文文档同步(本仓文档成对维护)**:README_en.md 按上述同一结构调整(核心特性表格新增 Documentation / Examples 两列、删除 ▶️ Usage Examples 与 📚 Related Documentation 章节、Quick Start 精简为一句导引、其余链接并入 Related Information);新增 examples/README_en.md 作为 examples/README.md 的英文版。组件用户指南目前仅有中文(docs/zh/),英文版链接指向中文文档并加说明,避免死链。 5. **快速开始恢复为可执行步骤**:原实现把「快速开始」压缩成一句导航句(「请先参考 X,随后按 Y,再参考 Z」),读者读完仍不知该敲什么命令、且要跳三个章节。按业界惯例(快速开始 = 从零到跑通的最短路径,而非导航目录)恢复为 4 步可复制命令:安装依赖 → 编译 → 安装 → 验证,并补一个可验证终点(asys -h)。参数穷举、离线编译、调试构建等仍留在「编译参数与依赖说明」,与快速开始分工。 6. **锚点落到无 emoji 的 h3 子标题**:源码编译 原为一整段无子标题,按内容拆为「加载环境变量 / 执行编译 / 编译参数与依赖说明」;安装与验证 沿用既有「安装 / 验证」。h2 的 emoji 全部保留不动,锚点一律指向这些 h3,且指向语义最贴近的子节(正文「按[源码编译](#执行编译)构建」落在「执行编译」,「[安装](#安装)与[验证](#验证)」分别落在两个子节)。原因见下方「锚点冲突」一节。 ## 锚点冲突(本 PR 曾因此 FAILED 两轮) 本仓锚点要同时满足两个判定方,二者对**含 emoji** 与**含 / ** 的标题给出的 slug 不同,这两类标题没有两边皆可的写法: | 标题形态 | GitCode 渲染(决定网页能否跳转) | 流水线 StaticCheck_link_validity(决定门禁) | | | --- | --- | --- | --- | | ## 🔧 源码编译 | #源码编译 | #-源码编译 | ⚠️ 冲突 | | ## asys(故障信息收集 / 诊断) | #asys故障信息收集-诊断 | #asys故障信息收集--诊断 | ⚠️ 冲突 | | ### 安装(纯文字) | #安装 | 同 | ✅ 一致 | | ## msprof(性能调优)(有括号无 emoji 无 /) | #msprof性能调优 | 同 | ✅ 一致 | 依据是门禁产物 link_validity_check.csv 的逐条对照:README.md 第 147–149 行同时含 #源码编译 与 #安装,**只有前者被拒**。 故本 PR 让锚点只落在「两边一致」的标题上:h2 保留 emoji 但不作锚点目标,其下拆出无 emoji 的 h3 承接锚点;asys 标题的 / 改为「与」后即可正常深链,因此核心特性表「运行示例」列三个组件保持统一的深链风格。该约定已写入仓内 gitcode-pr skill(另提 PR #464)。 ## 评审意见处理 - **@jinyingqi(major,已采纳)**:examples/README.md 中 9 处 ${ASCEND_INSTALL_PATH} 统一改为 ${ASCEND_HOME_PATH}。核实依据:build.sh:79 为 ASCEND_INSTALL_PATH="${ASCEND_HOME_PATH}",该变量由 build.sh 自行派生而非 set_env.sh 导出;examples/msaicerr/run.sh:19、examples/msprof/run.sh:19 亦用 ${ASCEND_INSTALL_PATH:-${ASCEND_HOME_PATH:-...}} 兜底,反证其不保证存在。英文版同步采用 ${ASCEND_HOME_PATH}。 - **@newstarzj**:四条意见已逐条核实并回复。其中「脚本未创建」经核实不成立(四个脚本由 ee4b95c 早已合入 master,属仓内既有文件,故不在本 PR diff 中);两条锚点死链不成立(README.md 存在 ## 📦 安装与验证,#-安装与验证 为其 emoji 剥离后的锚点,同写法在 master 已广泛使用);「保留 hiascend 外链」与 issue #168 第 3 条「链接指向仓内的组件文档」的验收要求冲突,已说明理由待评审确认。 ## 变更类型 请选择本次引入的变更类型(勾选对应项): - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [ ] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [ ] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue 关联 Issue #168 ## 如何测试 - 校验所有仓内文档链接目标存在:docs/zh/{asys,msaicerr,profiling,hccl_test}/README.md、docs/en/quick_install.md、examples/README_en.md、CONTRIBUTING_en.md、SECURITY_en.md 均存在。 - 校验 examples/README.md / examples/README_en.md 中相对链接(asys/run.sh、msaicerr/run.sh、msprof/run.sh、deploy.sh、../docs/zh/...、../README.md / ../README_en.md)均可解析。 - 校验中英锚点各自自洽:中文 #-源码编译、#-安装与验证;英文 #-source-code-compilation、#-installation-and-verification,以及 examples 英文版三个组件锚点。 - 确认根 README 与 README_en 均已无「相关文档」/「Related Documentation」章节,章节结构完整无断链。 - 本地全量 UT:python3 -m pytest test/ut/asys/ test/ut/msaicerr/ -q → 1104 passed(test_compile_op_ascend950.py::test_get_ub_size_not_tbe 为存量失败,在未含本 PR 改动的干净工作区复跑同样失败,与本次纯文档改动无关)。msprof gtest 需编译,本地未覆盖,依赖云端 UT_Test。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md) ## 其他信息 本次为纯文档改动,涉及 README.md、README_en.md、examples/README.md 与新增 examples/README_en.md 四个文件,不含代码逻辑变更。 See merge request: cann/oam-tools!443 | 5 天前 | |
fix(docs): update SECURITY.md protobuf version Co-authored-by: halaxy<2966011847@qq.com> # message auto-generated for no-merge-commit merge: !372 merge fix/docs-security-protobuf-version into master fix(docs): update SECURITY.md protobuf version Created-by: 2401_86136928 Commit-by: halaxy Merged-by: cann-robot Description: fix protobuf version in SECURITY.md. Closes #139 See merge request: cann/oam-tools!372 | 1 个月前 | |
fix(docs): update SECURITY.md protobuf version Co-authored-by: halaxy<2966011847@qq.com> # message auto-generated for no-merge-commit merge: !372 merge fix/docs-security-protobuf-version into master fix(docs): update SECURITY.md protobuf version Created-by: 2401_86136928 Commit-by: halaxy Merged-by: cann-robot Description: fix protobuf version in SECURITY.md. Closes #139 See merge request: cann/oam-tools!372 | 1 个月前 | |
fix: 闭源包按分支拉取,支持 --bundle_branch 与自动探测(#169) Co-authored-by: sinat_31531339<yuanyue23@huawei.com> # message auto-generated for no-merge-commit merge: !452 merge fix/issue-169-bundle-branch into master fix: 闭源包按分支拉取,支持 --bundle_branch 与自动探测(#169) Created-by: sinat_31531339 Commit-by: sinat_31531339 Merged-by: cann-robot Description: ## 描述 修复切换分支编译时闭源二进制包(bundle)始终固定拉取 master 分支包的问题。 OAM_BUNDLE_BRANCH 由硬编码 master 改为三级决策:**显式指定 > git 探测 > master 兜底**,并对结果做白名单硬校验(OBS 上无对应包的分支在配置阶段即报错,而非下载到 403 空包后把失败推迟到 install 阶段)。 取包的三条入口(已就绪的 bundle/ 目录、本地预置 tar、OBS 下载)**都要核对分支**——只修下载路径不够,因为切分支后最常走的恰恰是前两条。 **主要改动** - **build.sh 新增 --bundle_branch=<NAME>**:解析后存入 BUNDLE_BRANCH,仅在用户显式指定时透传 -DOAM_BUNDLE_BRANCH 给 CMake;不传则由 CMake 配置期自行探测。取值做字符白名单校验([A-Za-z0-9._/-]),拒绝含空格或 shell 元字符的分支名。BUNDLE_BRANCH 在 checkopts() 解析选项前显式清空,避免环境里的同名变量被当成"用户显式指定"——那样既盖掉自动探测,又绕过上述字符校验(校验只在 --bundle_branch 分支里跑)。 - **cmake/install_bundle.cmake 新增 oam_resolve_bundle_branch()**:实现三级决策。git 探测按**模式枚举**远端发布线分支(git for-each-ref refs/remotes + 正则 ^[0-9]+\.[0-9]+\.[0-9]+(-beta\.[0-9]+)?$),去掉 -beta.N 后缀归一化为 OBS 路径名(9.1.0-beta.3 → 9.1.0),取领先提交数最小者(血缘最近)。不硬编码任何具体 ref——同一发布线并存 9.1.0、9.1.0-beta.1/2/3 等多个分支,硬编码任一个都会让其余分支探测不到而静默回退 master。不限定 origin,fork 场景下发布线常只在 upstream。 - **已就绪的 bundle/ 目录也校验分支**:bundle/ 非空即跳过下载,是切分支后最常命中的路径;不校验就会静默复用上一条线的闭源包(连显式 --bundle_branch 也无效)。取包成功后在 bundle/.bundle_branch 落分支元数据(解压产物本身不含分支信息),复用前读取比对,不一致则 FATAL_ERROR 并提示 --make_clean 刷新或 --bundle_branch=<现有分支> 沿用现包。本改动之前拉下的 bundle 无元数据,降级为告警而非报错,避免既有工作目录必须先重下闭源包才能构建。 - **离线预置包按分支校验**:预置包文件名不含分支信息(各分支同名),命中后直接复用会静默混入其它分支的闭源包。cmake/download_libs.py 下载后在包旁写 <tar>.branch 元数据;install_bundle.cmake 命中预置包时读取并与目标分支比对,不一致则配置阶段 FATAL_ERROR。无元数据的既有包按旧约定放行并告警。 - **cmake/download_libs.py 支持 --bundle_branch,且元数据只反映本轮实际结果**:分支解析规则与白名单与 install_bundle.cmake 完全一致,使联网机器预置与离线机器联编两端对齐。元数据**只写本轮确实下载成功的 tar**(原先按"文件是否存在"写,会把目录里残留的旧分支包贴上本轮标签,联编时反而错误校验通过——比没有元数据更糟);本轮未取到的包会**清掉其陈旧元数据**,让联编侧如实走"无元数据"告警分支;bundle 一个都没取到时以非零码退出;wget -O 失败时删除残留的半截文件,避免被后续误当作可用预置包。 - **中英文档同步**:README.md / docs/zh/quick_install.md 与 README_en.md / docs/en/quick_install.md 四处改动一一对应,均说明按分支拉取规则、--bundle_branch 用法、离线预置须与联编分支一致,闭源包表格表头由「版本」改为「分支」。 - **新增测试 test/ut/asys/testcase/common/test_bundle_branch.py**:32 条用例。cmake 部分不做字符串匹配,而是在临时 git 仓/预置的 bundle 目录里真正跑 cmake 求值,覆盖:显式指定优先、9.1.0 线各分支(参数化 4 个)、master 探测、ref 均不存在回退、git 不可用回退、非 origin remote、OBS 无包发布线被忽略、已有 bundle 分支一致则复用 / 不一致则报错 / 无元数据则告警、预置包分支校验、元数据只给本轮下载成功者、两端白名单同步。 ## 变更类型 请选择本次引入的变更类型(勾选对应项): - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [ ] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [x] 📦 构建过程或辅助工具的变动 - [x] 📝 文档内容更新 ## 关联的Issue 关联 Issue #169 ## 如何测试 bash # 1) 自动探测(不传参数):从 9.1.0 线分支编译应拉 9.1.0 包,从 master 拉 master 包 bash build.sh # 2) 显式指定 bash build.sh --bundle_branch=9.1.0 # 3) 非法分支应在配置阶段报错并提示可用取值 bash build.sh --bundle_branch=nonexistent # 4) 非法字符应被入口校验拒绝 bash build.sh --bundle_branch='bad name' # 5) 切分支场景:master 构建后切到 9.1.0 直接构建,应报错提示 --make_clean 而非静默复用 bash build.sh # 在 master 上 git checkout 9.1.0-beta.3 bash build.sh # 应因 bundle/ 分支不符而报错 # 6) 离线预置两端一致 python cmake/download_libs.py --bundle_branch=9.1.0 bash build.sh --cann_3rd_lib_path=<预置目录> --bundle_branch=9.1.0 # 7) 单元测试 python3 -m pytest test/ut/asys/testcase/common/test_bundle_branch.py -v 本地验证: - 新增用例 32 passed。其中本轮新增的 7 条已逐条确认**修复前失败、修复后通过**(把 pre-fix 的三个文件单独取出跑同一份测试:7 failed)。 - test/ut/asys/ 全量 536 passed。 - test/ut/asys/ + test/ut/msaicerr/ 合计 1155 passed / 15 skipped,唯一失败 test_compile_op_ascend950.py::test_get_ub_size_not_tbe 为存量失败——把本 PR 全部改动 stash 后该用例同样失败,与本改动无关。 - cmake/download_libs.py 与新增测试跑过增量 codecheck 规则(E501/T201/S607/PLR0915/PLR6301/PLR1722),无告警。 - msprof gtest 需编译,本地未覆盖,依赖云端 UT_Test。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md) ## 其他信息 历轮评审共修复了六个实际缺陷: 1. -DOAM_BUNDLE_BRANCH=\"${BUNDLE_BRANCH}\" 的转义引号在 cmake ${cmake_args} .. 非引号展开时作为字面量传入 CMake,白名单比对必然失配,--bundle_branch 功能不可用(jinyingqi 指出,已实测复现)。 2. 硬编码 origin/9.1.0-beta.2 漏掉同一发布线的其它分支,从 9.1.0/beta.1/beta.3 编译都会静默回退 master(newstarzj 指出方向)。 3. cmake 中 --format=%(refname:short) 未加引号时括号被当作参数分隔符,git 只输出 %,探测全部失效(新增测试时发现)。 4. bundle/ 非空即 return,完全跳过分支解析与校验——切分支后最常走这条路径,旧闭源包被静默复用,PR 修复目标在主场景下失效(jinyingqi 指出)。 5. BUNDLE_BRANCH 未在 checkopts() 初始化,环境变量可绕过字符校验并覆盖自动探测(jinyingqi 指出)。 6. 离线预置元数据按"文件是否存在"写入,会把目录里残留的旧分支包标记为本轮分支,使联编侧错误校验通过(jinyingqi 指出)。 See merge request: cann/oam-tools!452 | 17 天前 | |
[Profiling]文档补充说明 msprof/msprobe 子仓的 gitcode 访问凭证要求 Co-authored-by: z296249221<zhengkai40@huawei.com> # message auto-generated for no-merge-commit merge: !441 merge docs/submodule-credential-notice into master [Profiling]文档补充说明 msprof/msprobe 子仓的 gitcode 访问凭证要求 Created-by: z296249221 Commit-by: z296249221 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动,包括改动的原因和所采取的方法。--> 文档补充说明 msprof/msprobe 子仓的 gitcode 访问凭证要求 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue,请在这里提供Issue链接。例如:关联Issue #000--> <!-- 如果这个PR是为了解决特定的问题单,请在这里描述问题单单号。--> Issue [#154](https://gitcode.com/cann/oam-tools/issues/154) ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> NA ## 文档更新 <!--如果这个PR包含文档的更新,请在这里指出。例如:更新了README.md文件。--> NA ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [x] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!441 | 1 个月前 | |
fix: init_env自动同步版本并安装依赖(#148) Co-authored-by: sinat_31531339<yuanyue23@huawei.com> # message auto-generated for no-merge-commit merge: !419 merge fix/init-env-issue148 into master fix: init_env自动同步版本并安装依赖(#148) Created-by: sinat_31531339 Commit-by: sinat_31531339 Merged-by: cann-robot Description: ## 描述 本 PR 解决 Issue #148 中 init_env.sh 默认安装版本硬编码为 8.5.0 的问题,并补齐初始化脚本在管道执行、依赖安装、异常路径下的行为。 主要改动: - init_env.sh 默认从 version.cmake 解析 CANN 版本号,不再硬编码默认版本;本地缺少 version.cmake 时支持从 OAM_TOOLS_RAW_BASE_URL 远程获取。 - install_python_deps 改为安装仓库 requirements.txt,本地缺失时支持远程获取;获取或安装失败时返回错误,避免静默跳过。 - 远程 requirements 安装改用临时文件,不再依赖 /dev/stdin;pip 失败时保留最后几行错误输出,方便定位网络、权限或包冲突问题。 - 非 root 用户不会执行 apt/yum 安装;缺少必需系统命令时明确提示 skipping installation (non-root user) 并返回失败,避免后续编译阶段才暴露问题。 - CANN 版本解析失败或解析结果为空时显式报错并退出,避免拼接空版本下载 URL。 - 修正 ops 包芯片类型映射:910_93/910C/A3 使用 A3,910B/910b 使用 910b,950 显式使用 950。 - 中英文 quick_install 文档删除执行脚本后手动安装 Python 依赖的旧步骤,与脚本自动安装行为保持一致。 ## 关联的Issue 关联 Issue #148 ## 测试 - bash -n init_env.sh - bash init_env.sh --help - bash -c 'source <(sed "$ d" init_env.sh); get_cann_version_from_cmake version.cmake' - bash -c 'source <(sed "$ d" init_env.sh); get_ops_package_chip_type 910_93; get_ops_package_chip_type 910C; get_ops_package_chip_type 910B; get_ops_package_chip_type 910b; get_ops_package_chip_type 950' - 模拟远程 version.cmake 获取失败,验证输出明确错误并返回失败。 - 模拟非 root 缺少 cmake,验证 install_system_deps 输出 non-root 跳过安装说明并返回失败。 - 模拟远程 requirements.txt 获取失败,验证输出明确错误并返回失败。 - 模拟 pip 安装失败,验证输出最后几行 pip 错误信息并返回失败。 - git diff --check -- init_env.sh docs/zh/quick_install.md docs/en/quick_install.md - bash build.sh -u --ut --noexec ## 文档更新 更新 docs/zh/quick_install.md 和 docs/en/quick_install.md,删除过时的手动 pip install -r requirements.txt 步骤。 ## 类型标签 - [x] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [ ] 🔧 配置变更 - [x] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!419 | 1 个月前 | |
chore: 精简未使用 Python 依赖(#166) Co-authored-by: sinat_31531339<yuanyue23@huawei.com> # message auto-generated for no-merge-commit merge: !433 merge fix/issue-166-python-deps into master chore: 精简未使用 Python 依赖(#166) Created-by: sinat_31531339 Commit-by: sinat_31531339 Merged-by: cann-robot Description: ## 描述 - 从 requirements.txt 中移除未被项目运行时直接使用的 pytest-cov、ruff、yapf、PyYAML、requests。 - coverage 已由 scripts/run_tests.sh 通过 python3 -m coverage 直接调用,无需 pytest-cov 插件。 - ruff 由 pre-commit hook 的隔离环境管理,requirements.txt 中不再重复声明。 - pandas 和 h5py 暂保留:构建同步出的 msaccucmp 比对能力中存在 CSV/HDF5 解析使用点,直接删除会带来运行时缺依赖风险。 ## 移除依赖的核实证据(可追溯性) 每个被移除依赖均已全局搜索确认在本项目代码( src/、scripts/)中无 import 引用,仅测试虚拟环境 .venv_test/ 下的第三方包使用(非项目运行时代码): | 依赖 | 核实结论 | |------|----------| | PyYAML | src/、scripts/ 无 import yaml / from yaml;仅 .venv_test/ 第三方包(torch 等)使用 | | requests | src/、scripts/ 无 import requests / from requests;仅 .venv_test/ 第三方包(fsspec、sympy 等)使用 | | pytest-cov | 覆盖率收集在 scripts/run_tests.sh:471 用 python3 -m coverage run --source=... -m pytest,非 pytest --cov;全仓无 pytest --cov 用法,coverage 依赖已保留 | | ruff | 由 pre-commit 隔离环境统一管理(.pre-commit-config.yaml),scripts/incremental_codecheck.py 作为 pre-commit 钩子在该环境运行,不依赖 requirements.txt | | yapf | 本项目代码无任何引用 | ## 关联的Issue 关联 Issue #166 ## 测试 - python3 -m pip install --dry-run --no-deps -r requirements.txt - python3 -m pytest test/ut/asys/ test/ut/msaicerr/ -q(1011 passed, 5 skipped) - git diff --check ## 文档更新 无 ## 类型标签 - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [x] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [x] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/oam-tools!433 | 1 个月前 | |
fix: 更新 version.cmake 依赖列表与版本格式 (#142) Co-authored-by: sinat_31531339<yuanyue23@huawei.com> # message auto-generated for no-merge-commit merge: !381 merge fix/issue-142-version-dependencies into master fix: 更新 version.cmake 依赖列表与版本格式 (#142) Created-by: sinat_31531339 Commit-by: sinat_31531339 Merged-by: cann-robot Description: ## 描述 ### Issue #142 - oam-tools 仓依赖版本号不正确 **问题:** version.cmake 依赖列表的版本号未使用语义化版本约束格式。 **修复内容:** 1. **版本格式更新** - "9.0" → ">=9.0" (语义化版本约束,允许向前兼容) 2. **包版本号更新** - set_cann_package(oam-tools VERSION "9.0.0") → "9.1.0" 3. **格式规范** - 统一使用英文引号(issue 中混用了中文引号,可能导致兼容性问题) ## 变更类型 请选择本次引入的变更类型(勾选对应项): - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新(格式化,局部变量) - [ ] ♻️ 重构(既不修复错误也不增加功能的代码变动) - [x] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 在 PR 右侧「关联 Issue」面板添加链接;「合并后关闭已关联的 Issue」保持不勾选,issue 由用户在合入后手动关闭。 --> 关联 Issue #142 ## 如何测试 1. CMake 语法检查 2. pre-commit 检查通过(OAT、codespell) 3. 云端构建流水线验证依赖解析 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签(如:feat:, fix:) - [x] 我已经详细阅读了贡献指南(CONTRIBUTING.md) ## 其他信息 无 See merge request: cann/oam-tools!381 | 1 个月前 |
📖 项目简介
OAM-Tools(Operations, Administration, and Maintenance)是华为 CANN 的开源运维工具集,为昇腾 AI 处理器开发者提供故障定位与性能调优两大核心能力。工具集覆盖从故障信息采集、AI Core Error 分析到 AI 任务性能采集与分析的完整运维链路,帮助开发者快速定位软硬件问题、优化 AI 任务性能。
适用场景:
- AI 训练/推理任务运行异常时,一键采集故障信息、分析 AI Core Error 根因
- AI 任务性能调优,采集各运行阶段关键性能指标,定位性能瓶颈
- 分布式训练场景下,测试集合通信(HCCL)的功能与性能
✨ 核心特性
OAM-Tools 包含四大核心组件,协同覆盖昇腾 AI 处理器的运维全场景:
| 组件 | 功能定位 | 核心能力 | 文档 | 运行示例 |
|---|---|---|---|---|
| asys(故障信息收集) | 一键式故障信息采集与诊断 | 故障信息收集、业务复跑+信息收集、软硬件/Device 状态展示、健康检查、综合检测、组件检测、trace/coredump/stackcore/coretrace/UB 文件解析、实时堆栈导出、AI Core Error 故障信息解析、性能数据采集 | 用户指南 | 示例 |
| msaicerr(AI Core Error 分析) | AI Core Error 问题定位 | AI Core Error 问题分析、Dump 文件解析与数据类型转换、运行环境检查 | 用户指南 | 示例 |
| msprof(性能调优) | AI 任务性能采集与分析 | 采集 AI 任务运行性能数据、AI 处理器系统数据、Host 侧系统数据、msproftx 数据;支持动态/延迟采集;提供 ACL/Ascend Graph/acl.json/环境变量多种采集方式 | 用户指南 | 示例 |
| hccl_test(HCCL 性能测试) | 集合通信功能与性能测试 | 分布式训练/推理场景下,基于 HCCL 单算子 API 测试集合通信的功能正确性与性能 | 用户指南 | — |
🏗️ 项目架构
OAM-Tools 采用模块化设计,四大组件相互独立又协同工作:asys 与 msaicerr 聚焦故障诊断,msprof 聚焦性能分析,hccl_test 聚焦通信测试。所有组件共享 CANN 运行时环境,通过统一的构建系统(CMake + build.sh)编译打包为 .run 安装包,安装后释放到 CANN 安装目录的 tools/ 子目录下。
目录结构:
oam-tools/
├── cmake/ # 构建配置(CMake 模块、第三方库下载脚本)
├── scripts/ # 辅助构建与检查脚本(oat_check.sh 等)
├── src/ # 源代码
│ ├── asys/ # asys:故障信息收集工具(Python)
│ ├── msaicerr/ # msaicerr:AI Core Error 分析工具(Python)
│ ├── msprof/ # msprof:性能调优工具(C++ collector + Python 分析脚本)
│ ├── hccl_test/ # hccl_test:HCCL 性能测试工具(C++)
│ ├── operator_cmp/ # 算子比对工具
│ └── third_party/ # 依赖的第三方库头文件
├── test/ # UT/ST 测试用例
├── docs/ # 项目文档(中/英文)
│ ├── zh/ # 中文文档(asys/msaicerr/profiling/hccl_test 用户指南)
│ ├── en/ # 英文文档
│ └── figures/ # 图片资源
├── init_env.sh # 开发环境一键安装脚本
├── build.sh # 项目编译脚本
├── CMakeLists.txt # CMake 主配置文件
└── version.cmake # 版本与依赖声明
🧩 支持的硬件环境
在搭建环境之前,请先确认硬件在本工具的支持范围内,若无昇腾设备也可以通过 docker 方式编译构建(详见快速安装)。
-
CPU 架构:
aarch64、x86_64 -
昇腾 AI 处理器:
npu-smi infoName 列适用产品 对应 CANN ops 包代号 910BAtlas A2 训练系列产品 / Atlas 800I A2 推理产品 910b910_93Atlas A3 训练系列产品 / Atlas A3 推理系列产品(业内"910C"对应此项) A3950Atlas 950 系列产品 950npu-smi info实际可能显示带子型号的字符串(如910B1/910B2/910B3/910B4),按"Name 列包含上述关键字"的规则匹配即可。- "910C"是商用别称。自 CANN 8.5.0 起,ops 包统一命名为
Ascend-cann-A3-ops_*,请勿在包名中拼写为910c、910_c、910_93等形式。 - 其它芯片暂不支持,欢迎提交 issue 反馈。CANN ops 包名拼接规则与下载详见快速安装。
🚀 快速开始:从零编译到验证
以下为 root 用户默认安装路径下从零跑通的最短路径,四步即可得到可用的工具。第三方库定制、离线编译、调试构建等完整参数,以及分组件的测试验证方式,见后续的「源码编译」与「安装与验证」章节。
1. 安装依赖
参考快速安装指南完成 CANN 软件包与编译依赖的安装。
2. 编译
# 非 root 用户将 /usr/local 替换为 ${HOME}
source /usr/local/Ascend/cann/set_env.sh
bash build.sh
编译产物为 build_out/cann-oam-tools_<cann_version>_linux-<arch>.run(<arch> 为 x86_64 或 aarch64)。
3. 安装
./build_out/cann-oam-tools_<cann_version>_linux-<arch>.run --full
4. 验证
重新加载环境变量后调用 asys,能正常打印帮助信息即表示安装成功:
source /usr/local/Ascend/cann/set_env.sh
asys -h
需要在真实环境中跑通各组件功能,见运行示例。
🔧 源码编译
加载环境变量
编译前请先根据 CANN 安装路径加载环境变量:
source <CANN安装路径>/set_env.sh
root 用户默认路径为
/usr/local/Ascend/cann;非 root 用户默认为${HOME}/Ascend/cann;指定路径安装时为${install_path}/cann。
执行编译
执行以下命令进行编译:
bash build.sh
如需指定第三方库路径,可通过 --cann_3rd_lib_path 参数传入:
bash build.sh --cann_3rd_lib_path=${third_party_path}
编译参数与依赖说明
--cann_3rd_lib_path:第三方库存储目录,默认值为./third_party。若本地不存在第三方库,编译脚本将自动从 gitcode 开源仓库下载各第三方库源码。- 编译过程中会自动下载闭源二进制包,该包含有保证功能正常运行所需的库及头文件,且仅提供 release 版本,即使编译选项指定为 debug,也只会下载 release 版本的 tar 包。
- 闭源二进制包按分支拉取:不指定时,编译脚本会依据当前 git 提交自动探测所属发布分支(从
master拉出的分支拉 master 包,从 9.1.0 线拉出的分支拉 9.1.0 包),探测不出时回退master。也可通过--bundle_branch=<NAME>显式指定分支,个人分支探测不准时建议显式指定。当前 OBS 上提供包的分支为master与9.1.0;指定其它分支会在配置阶段报错。 - 编译过程中会通过
git clone拉取msprof和msprobe子仓(分别用于构建 msprof 分析 wheel 和同步 msaccucmp 工具)。子仓源码位于 gitcode,使用 HTTPS 协议克隆前需配置 gitcode 个人访问令牌以替代登录密码,否则克隆会失败。 - 若编译环境无法访问网络,请参考离线编译环境准备提前完成依赖包的下载与配置,并通过
--cann_3rd_lib_path参数指定依赖包所在目录后再执行编译。离线预置脚本cmake/download_libs.py同样支持--bundle_branch指定要预置的闭源包分支(默认自动探测),须与联编时的分支保持一致。 - 闭源二进制包会解压到仓库根目录的
bundle/下。若bundle/已存在且非空,构建会复用该目录并跳过下载;如需强制重新下载或修复残缺的bundle/目录,可执行bash build.sh --make_clean后重新编译,也可手动删除bundle/后再次执行bash build.sh。 - 更多编译参数请通过
bash build.sh -h查看。
编译完成后,build_out 目录下会生成 cann-oam-tools_<cann_version>_linux-<arch>.run 软件包,其中 <cann_version> 为版本号,<arch> 为操作系统架构(可选值:x86_64 或 aarch64)。
📦 安装与验证
安装
可执行如下命令安装编译生成的 oam-tools 软件包:
./build_out/cann-oam-tools_<cann_version>_linux-<arch>.run --full --install-path=${install_path}
安装完成之后,用户编译生成的 oam-tools 软件包会替换已安装 CANN 开发套件包中的 oam-tools 相关软件。
如果您的环境上
grep版本大于 3.8.0,安装时会出现告警,例如grep: warning: stray \ before -,这是由于 grep 高版本对表达式有更严格的校验,但并不影响安装和使用。
验证
编译完成后,用户可以进行测试验证项目功能是否正常。
Python 依赖安装已在环境准备中处理,无需额外操作。
# 执行所有组件测试
bash build.sh -u
# 指定单独组件测试(可选:asys / msaicerr / msprof / install / upgrade / uninstall / all)
bash build.sh -u --component msprof
--component 与测试范围、环境准备章节的对应关系如下:
| component | 测试范围 | 环境准备索引 | 示例 |
|---|---|---|---|
asys |
asys Python UT + ST | 环境准备、环境变量配置 | bash build.sh -u --component asys |
msaicerr |
msaicerr Python UT + ST | 环境准备、环境变量配置 | bash build.sh -u --component msaicerr |
msprof |
msprof C++ gtest UT | 源码编译、离线编译环境准备 | bash build.sh -u --component msprof --ut |
install |
安装包安装 ST | 源码编译、安装 | bash build.sh -u --component install --st |
upgrade |
安装包升级 ST | 源码编译、安装 | bash build.sh -u --component upgrade --st |
uninstall |
安装包卸载 ST | 源码编译、安装 | bash build.sh -u --component uninstall --st |
all |
全部可用 UT + ST | 环境准备、源码编译 | bash build.sh -u |
install、upgrade、uninstall仅包含 ST,用例依赖build_out/cann-oam-tools_<cann_version>_linux-<arch>.run。推荐通过上表中的build.sh -u --component ... --st运行,脚本会先完成构建打包;若直接执行scripts/run_tests.sh,需先确保build_out/下已有可用.run包。
UT 测试用例编译输出目录为 build,如果想清除历史编译记录:
rm -rf build_out/ build/
🅿️ Pre-commit
pre-commit 是一个用于管理和维护 Git 预提交钩子(hooks)的框架,通过在代码提交前自动化执行代码检查、格式化和安全扫描,确保代码质量并统一团队规范,显著减少 CI/CD 流水线失败并提升协作效率。
本仓已配置 pre-commit,用户可以参考 CANN 社区的pre-commit 配置指导书中第 3 章节安装 pre-commit。OAT 检查工具已改用 Python 版本 oat-py(通过 pip install oat-py>=1.0.0 安装),无需配置 Java/Maven 环境;首次运行时 pre-commit 会为各 hook 创建隔离的虚拟环境,耗时稍长。