CANN Runtime 开源贡献指南从 Issue 到 PR 的完整贡献流程与研发规范体系【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime本文以 CANN Runtime 仓库根目录的 CONTRIBUTING.md 为主线系统梳理参与该开源项目的完整贡献路径从参与前的准备、Bug 修复/文档纠错/协助他人三大贡献场景到提交 PR 前的规范阅读、pre-commit 本地检查与 CI 流水线校验。读完本文您将掌握在 Runtime 仓中规范化提交代码所需的全部操作要点并能通过仓库内现成的编码规范、UT 规范与设计文档模板把改动打磨到可合入的质量。一、贡献前的准备工作Runtime 仓库欢迎开发者体验并参与贡献。根据 CONTRIBUTING.md 的说明在正式参与社区贡献之前需要先完成三项准备了解行为准则阅读 CANN 社区cann-community仓库中的行为准则明确社区协作的基本约定签署 CLA 协议完成贡献者许可协议的签署这是代码被合入的前置条件熟悉源码仓贡献流程了解 Issue、PR、CI 校验等各环节的通用流程。这三项准备均指向仓库外部的社区公共约定本文不再展开重点放在进入本仓库之后需要遵守的规范与流程上。二、仓库的研发规范体系总览CONTRIBUTING.md 明确要求开发者在编码、编写测试和准备设计方案前请优先阅读docs/zh/guidelines/目录下的开发指南并遵从其中的相关规范。该目录由 docs/zh/guidelines/README.md 总览沉淀了 Runtime 仓的软件设计模板、编码规范、测试用例规范和代码检视规则包含以下文档文档内容适用场景design_document_template.mdRuntime 设计文档模板包含接口、架构、文档同步和 DT 检查项输出设计方案、接口设计、特性设计时coding-guidelines.mdRuntime 代码实现时应遵守的统一编码规范日常开发、自检、PR 评审时ut-coding-guidelines.mdRuntime UT 代码的硬性规范补充测试实现层面的约束编写、修改、审查 UT 代码时Runtime Error Message 开发总纲Runtime/ACL Error Message 整改和检视的统一规范包含错误码选择、ErrMsg 上报宏选择、错误文案和上报边界新增或整改 ErrMsg 上报、选择 EE/EH 错误码、优化错误文案、执行 ErrMsg 自检或评审时DT用例开发总纲Runtime 仓 UT/ST 用例的组织方式、接入流程和通用规范新增或修改测试时pre-commit_guide.mdRuntime pre-commit 配置与使用说明包含 clang-format 格式化和 OAT 合规检查提交代码前安装、运行CONTRIBUTING.md还给出了三条必须遵循的原则可直接作为自检清单修改源码前先阅读并遵守对应的编码规范修改 UT 代码时除通用编码规范外还应同时遵守 ut-coding-guidelines.md 和 UT 用例开发指导涉及新增能力、接口或流程调整的改动应先补充设计说明再开始编码。编码规范的核心约束coding-guidelines.md 分为两部分通用 C/C 编码规范适用于仓内所有源码和 UT 代码Runtime 约束性规范主要适用于src/、include/、pkg_inc/、cmake/等目录。其中通用部分的核心规则包括规则 1禁止硬编码敏感信息——源码中禁止硬编码明文密码、密钥硬编码公网 IP、域名、邮箱等必须能说明合理用途规则 2外部数据作为数组索引或指针偏移时——必须先做严格范围校验防止越界访问规则 3整数运算——参与内存申请、偏移计算、循环边界的运算必须评估溢出、反转、截断和除零风险规则 4资源管理和生命周期清晰——文件句柄、内存以及 device、context、stream、event、notify 等句柄必须在生命周期结束后及时释放异常分支和早返回路径不能遗漏清理动作优先使用 RAII 管理资源规则 5内存申请前后校验——申请前检查大小合法性不能申请 0 长度内存申请后校验是否成功规则 6外部输入先校验——用户参数、driver 返回值、配置文件、环境变量等进入关键逻辑前必须完成合法性校验解引用前确认指针有效规则 7错误处理完整禁止吞错——调用链上的错误返回值必须正确传播返回的错误码必须语义准确错误路径上已申请的资源必须同步释放规则 8缓冲区与对象生命周期安全——数组访问避免越界new/delete、malloc/free严格配对new(std::nothrow)必须判空禁止返回栈空间地址。这些规则与 Runtime 作为设备运行时组件的定位高度一致源码中大量涉及 device、stream、event 等长生命周期句柄的管理资源泄漏或错误码丢失会直接影响上层应用稳定性。设计文档模板的使用场景涉及新增特性、新增接口、新增配置参数或修改代码流程的改动CONTRIBUTING.md 建议先按 设计文档模板 完成设计说明。模板要求按“简介目的/范围→ 总体概述软件概述、功能、设计约束、假设与依赖→ 逐特性需求分析与设计”的结构组织内容并在产品环境介绍中明确相关组件的职责边界与外部接口如aclrt*、rt*、driver、toolchain、profiling、dump 等同时要求说明平台能力限制、公共 API/ABI 兼容性要求、构建宏约束等设计约束。三、提交 PR 前的两条硬性要求CONTRIBUTING.md 对提交 PR 提出了两点重点关注事项按 PR 模板完整填写。本仓库的 PR 模板为 .gitcode/PULL_REQUEST_TEMPLATE.zh-CN.md要求填写描述清晰描述本次 PR 的意图和变更内容变更类型Bug 修复 / 新功能 / 代码风格更新 / 重构 / 构建过程或辅助工具变动 / 文档内容更新关联的 Issue若 PR 为解决特定 Issue 而发起需在关联 Issue 部分添加链接并勾选“合并后关闭已关联的 Issue”如何测试描述测试此变更的步骤和前提条件核对清单代码遵循项目代码风格、已完成自测、已更新相关文档、标题使用合适类型标签如feat:、fix:、已详细阅读并遵守贡献指南包括 commit message 格式、无效 commit 的合并等其他信息任何附加说明。非简单 bug 修复必须先走 Issue 方案讨论。若修改涉及新增特性、新增接口、新增配置参数或修改代码流程务必先通过 Issue 进行方案讨论以避免代码被拒绝合入若不确定本次修改是否可归为“简单的 bug 修复”也建议通过提交 Issue 进行方案讨论。这条要求与后文 CI 流程相呼应仓库的 PR 流水线.gitcode/workflows/PR-pipeline_runtime.yml会对提交执行预构建、编译、静态检查、LLT 测试等多个阶段见stage1: PreBuild、stage2: Compile等配置未经方案对齐的改动即使通过编译也缺乏合入依据。四、三大贡献场景与操作细节CONTRIBUTING.md 将开发者贡献场景归纳为三类Bug 修复、文档纠错、帮助解决他人 Issue。仓库中对应的 Issue 模板位于 .gitcode/ISSUE_TEMPLATE/ 目录包含 bug-report、documentation、feature-request、question 四类模板。场景一Bug 修复发现 Bug 后欢迎新建 Issue 进行反馈和跟踪处理。操作要点按社区指引新建Bug-Report|缺陷反馈类 Issue 描述 Bug。本仓库提供的模板为 .gitcode/ISSUE_TEMPLATE/bug-report.yml标题前缀固定为[Bug-Report|缺陷反馈]自动附加bug-report标签并包含五个必填项和一个选填项问题描述必填提供尽可能多的信息描述产生了什么问题环境信息必填提供昇腾硬件型号与软件环境信息重现步骤必填描述如何重现该缺陷预期结果必填描述期望的行为应该是什么样日志/截图必填提供尽可能多的日志或结果信息备注选填补充其他需要提供的信息。在 Issue 评论框中输入/assign或/assign yourself将该 Issue 分配给自己进行处理。场景二文档纠错若发现算子文档描述错误欢迎新建 Issue 进行反馈和修复按社区指引新建Documentation|文档反馈类 Issue 指出对应文档的问题本仓库对应模板为 .gitcode/ISSUE_TEMPLATE/documentation.yml同样在评论框中输入/assign或/assign yourself将 Issue 分配给自己纠正对应文档描述。本仓库文档量大且分层明确API 参考、开发指南、FAQ、错误码参考、日志参考、环境变量等文档纠错时建议先在对应目录内检索相关章节确认错误表述的准确位置与影响范围后再动手。场景三帮助解决他人 Issue如果社区中他人遇到的问题您有合适的解决方法欢迎在 Issue 中发表评论交流帮助他人解决问题和痛点共同优化易用性如果对应 Issue 需要进行代码修改可以在 Issue 评论框中输入/assign或/assign yourself将该 Issue 分配给自己跟踪协助解决问题。五、本地开发工具链pre-commit 检查CONTRIBUTING.md 将 pre-commit 使用方法 列为规范文档之一其作用是“适用于配置 pre-commit并在提交代码前运行格式化与合规检查”。该指导书与本仓库实际配置文件 .pre-commit-config.yaml 对应可验证如下细节。配置的检查项仓库的 .pre-commit-config.yaml 配置了两个 hookHook功能说明clang-formatC/C 代码格式化自动格式化代码保持风格一致OAT Check开源合规检查检测许可证头、禁止二进制文件提交其中 clang-format hook 的具体配置为使用 mirrors-clang-format 的v16.0.0版本作用于c/c类型文件文件后缀覆盖.c .h .cpp .hpp .cc .hh .cxx .hxx通过--stylefile参数遵循项目根目录的.clang-format配置-i表示原地修改明确排除了pkg_inc/profiling/aprof_pub.h以及include/external/acl/下的acl_prof.h、acl_rt*.h、acl_tdt*.h等外部接口头文件——这些文件作为对外 API 头文件格式风格以对外发布版本为准。而 OAT Check 是一个local类型的 hook入口脚本为bash scripts/oat_check.sh见 .pre-commit-config.yaml对提交的文件执行开源合规审计并排除了.pre-commit-config.yaml本身、README.md、Third_Party_Open_Source_Software_List.yaml等已知豁免文件。仓库根目录的 OAT.xml 即 OAT 工具使用的许可证检查规则配置。环境要求Git2.0Python3.8Java17OAT 工具依赖可自动安装clang-format14.0代码格式化Maven3.6OAT 工具依赖可自动安装安装与使用# 1. 安装 pre-commit pip install pre-commit # 或使用系统包管理器 sudo apt install pre-commit # 2. 安装依赖工具Ubuntu/Debian 示例 sudo apt install clang-format openjdk-17-jre maven # 3. 在项目根目录安装 Git Hooks cd /path/to/runtime pre-commit install # 安装成功后显示pre-commit installed at .git/hooks/pre-commit日常提交时每次执行git commit会自动运行检查输出形如clang-format.............................................................Passed OAT Compliance Check.....................................................Passed也可以手动运行# 运行所有检查 pre-commit run # 运行特定类型检查 pre-commit run clang-format pre-commit run oat-check # 检查所有文件不限于暂存区 pre-commit run --all-files紧急情况可跳过检查仅紧急情况下使用正常开发流程应保证检查通过git commit --no-verify -m emergency fixOAT 检查首次运行时会自动检测/安装 Java 17 与 Maven并克隆编译 tools_oat 工具约 1-2 分钟后续提交会使用缓存的 JAR速度很快。OAT 的检查项包括许可证头检查确保源文件包含 CANN License 头、二进制文件检查禁止提交二进制文件、归档文件检查禁止提交 zip/tar 等归档文件。六、代码提交后的 CI 校验本地 pre-commit 通过后PR 进入服务端流水线。从 .gitcode/workflows/PR-pipeline_runtime.yml 可以看到Runtime 的 PR 流水线以阶段stage方式组织例如stage1: PreBuild预构建含测试镜像选择与stage2: Compile编译并配套了 compile_action.yml、staticcheck_action.yml、llt_action.yml 等子流水线预构建、编译、静态检查、LLT 测试。流水线还支持在 PR 评论中输入/compile类指令触发编译见 workflow 的comments: [ ^(?:\/)?compile* ]触发配置配合并发控制concurrency.max: 15超出排队。从源码结构看/assign、/compile等评论指令与 Issue 分配、流水线触发构成了本仓库社区协作的自动化骨架贡献者通过 Issue 认领问题通过 PR 模板声明变更类型与测试方式再由流水线统一把关。七、贡献流程速查清单把 CONTRIBUTING.md 与仓库配套设施串起来一次完整贡献可按以下清单执行定位场景Bug 修复 / 文档纠错 / 帮助他人 Issue选择对应的 Issue 模板见 .gitcode/ISSUE_TEMPLATE/新建 Issue 并用/assign认领方案对齐非简单 bug 修复新增特性/接口/配置/流程改动先在 Issue 中完成方案讨论并按 设计文档模板 输出设计说明编码自检遵守 编码规范改动 UT 时叠加遵守 UT 代码规范 与 UT 用例开发指导涉及错误码/错误文案时参照 Error Message 开发总纲本地检查按 pre-commit 指导 安装 hook提交前确保 clang-format 与 OAT 合规检查全部 Passed提交 PR按 PR 模板 填写描述、变更类型、关联 Issue、测试步骤与核对清单等待 CI预构建/编译/静态检查/LLT通过后进入评审合入。遵循以上流程您的贡献即可在规范、工具链与流程三个层面与 Runtime 仓库保持对齐显著降低代码被拒绝合入的概率。【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CANN Runtime 开源贡献指南：从 Issue 到 PR 的完整贡献流程与研发规范体系
CANN Runtime 开源贡献指南从 Issue 到 PR 的完整贡献流程与研发规范体系【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime本文以 CANN Runtime 仓库根目录的 CONTRIBUTING.md 为主线系统梳理参与该开源项目的完整贡献路径从参与前的准备、Bug 修复/文档纠错/协助他人三大贡献场景到提交 PR 前的规范阅读、pre-commit 本地检查与 CI 流水线校验。读完本文您将掌握在 Runtime 仓中规范化提交代码所需的全部操作要点并能通过仓库内现成的编码规范、UT 规范与设计文档模板把改动打磨到可合入的质量。一、贡献前的准备工作Runtime 仓库欢迎开发者体验并参与贡献。根据 CONTRIBUTING.md 的说明在正式参与社区贡献之前需要先完成三项准备了解行为准则阅读 CANN 社区cann-community仓库中的行为准则明确社区协作的基本约定签署 CLA 协议完成贡献者许可协议的签署这是代码被合入的前置条件熟悉源码仓贡献流程了解 Issue、PR、CI 校验等各环节的通用流程。这三项准备均指向仓库外部的社区公共约定本文不再展开重点放在进入本仓库之后需要遵守的规范与流程上。二、仓库的研发规范体系总览CONTRIBUTING.md 明确要求开发者在编码、编写测试和准备设计方案前请优先阅读docs/zh/guidelines/目录下的开发指南并遵从其中的相关规范。该目录由 docs/zh/guidelines/README.md 总览沉淀了 Runtime 仓的软件设计模板、编码规范、测试用例规范和代码检视规则包含以下文档文档内容适用场景design_document_template.mdRuntime 设计文档模板包含接口、架构、文档同步和 DT 检查项输出设计方案、接口设计、特性设计时coding-guidelines.mdRuntime 代码实现时应遵守的统一编码规范日常开发、自检、PR 评审时ut-coding-guidelines.mdRuntime UT 代码的硬性规范补充测试实现层面的约束编写、修改、审查 UT 代码时Runtime Error Message 开发总纲Runtime/ACL Error Message 整改和检视的统一规范包含错误码选择、ErrMsg 上报宏选择、错误文案和上报边界新增或整改 ErrMsg 上报、选择 EE/EH 错误码、优化错误文案、执行 ErrMsg 自检或评审时DT用例开发总纲Runtime 仓 UT/ST 用例的组织方式、接入流程和通用规范新增或修改测试时pre-commit_guide.mdRuntime pre-commit 配置与使用说明包含 clang-format 格式化和 OAT 合规检查提交代码前安装、运行CONTRIBUTING.md还给出了三条必须遵循的原则可直接作为自检清单修改源码前先阅读并遵守对应的编码规范修改 UT 代码时除通用编码规范外还应同时遵守 ut-coding-guidelines.md 和 UT 用例开发指导涉及新增能力、接口或流程调整的改动应先补充设计说明再开始编码。编码规范的核心约束coding-guidelines.md 分为两部分通用 C/C 编码规范适用于仓内所有源码和 UT 代码Runtime 约束性规范主要适用于src/、include/、pkg_inc/、cmake/等目录。其中通用部分的核心规则包括规则 1禁止硬编码敏感信息——源码中禁止硬编码明文密码、密钥硬编码公网 IP、域名、邮箱等必须能说明合理用途规则 2外部数据作为数组索引或指针偏移时——必须先做严格范围校验防止越界访问规则 3整数运算——参与内存申请、偏移计算、循环边界的运算必须评估溢出、反转、截断和除零风险规则 4资源管理和生命周期清晰——文件句柄、内存以及 device、context、stream、event、notify 等句柄必须在生命周期结束后及时释放异常分支和早返回路径不能遗漏清理动作优先使用 RAII 管理资源规则 5内存申请前后校验——申请前检查大小合法性不能申请 0 长度内存申请后校验是否成功规则 6外部输入先校验——用户参数、driver 返回值、配置文件、环境变量等进入关键逻辑前必须完成合法性校验解引用前确认指针有效规则 7错误处理完整禁止吞错——调用链上的错误返回值必须正确传播返回的错误码必须语义准确错误路径上已申请的资源必须同步释放规则 8缓冲区与对象生命周期安全——数组访问避免越界new/delete、malloc/free严格配对new(std::nothrow)必须判空禁止返回栈空间地址。这些规则与 Runtime 作为设备运行时组件的定位高度一致源码中大量涉及 device、stream、event 等长生命周期句柄的管理资源泄漏或错误码丢失会直接影响上层应用稳定性。设计文档模板的使用场景涉及新增特性、新增接口、新增配置参数或修改代码流程的改动CONTRIBUTING.md 建议先按 设计文档模板 完成设计说明。模板要求按“简介目的/范围→ 总体概述软件概述、功能、设计约束、假设与依赖→ 逐特性需求分析与设计”的结构组织内容并在产品环境介绍中明确相关组件的职责边界与外部接口如aclrt*、rt*、driver、toolchain、profiling、dump 等同时要求说明平台能力限制、公共 API/ABI 兼容性要求、构建宏约束等设计约束。三、提交 PR 前的两条硬性要求CONTRIBUTING.md 对提交 PR 提出了两点重点关注事项按 PR 模板完整填写。本仓库的 PR 模板为 .gitcode/PULL_REQUEST_TEMPLATE.zh-CN.md要求填写描述清晰描述本次 PR 的意图和变更内容变更类型Bug 修复 / 新功能 / 代码风格更新 / 重构 / 构建过程或辅助工具变动 / 文档内容更新关联的 Issue若 PR 为解决特定 Issue 而发起需在关联 Issue 部分添加链接并勾选“合并后关闭已关联的 Issue”如何测试描述测试此变更的步骤和前提条件核对清单代码遵循项目代码风格、已完成自测、已更新相关文档、标题使用合适类型标签如feat:、fix:、已详细阅读并遵守贡献指南包括 commit message 格式、无效 commit 的合并等其他信息任何附加说明。非简单 bug 修复必须先走 Issue 方案讨论。若修改涉及新增特性、新增接口、新增配置参数或修改代码流程务必先通过 Issue 进行方案讨论以避免代码被拒绝合入若不确定本次修改是否可归为“简单的 bug 修复”也建议通过提交 Issue 进行方案讨论。这条要求与后文 CI 流程相呼应仓库的 PR 流水线.gitcode/workflows/PR-pipeline_runtime.yml会对提交执行预构建、编译、静态检查、LLT 测试等多个阶段见stage1: PreBuild、stage2: Compile等配置未经方案对齐的改动即使通过编译也缺乏合入依据。四、三大贡献场景与操作细节CONTRIBUTING.md 将开发者贡献场景归纳为三类Bug 修复、文档纠错、帮助解决他人 Issue。仓库中对应的 Issue 模板位于 .gitcode/ISSUE_TEMPLATE/ 目录包含 bug-report、documentation、feature-request、question 四类模板。场景一Bug 修复发现 Bug 后欢迎新建 Issue 进行反馈和跟踪处理。操作要点按社区指引新建Bug-Report|缺陷反馈类 Issue 描述 Bug。本仓库提供的模板为 .gitcode/ISSUE_TEMPLATE/bug-report.yml标题前缀固定为[Bug-Report|缺陷反馈]自动附加bug-report标签并包含五个必填项和一个选填项问题描述必填提供尽可能多的信息描述产生了什么问题环境信息必填提供昇腾硬件型号与软件环境信息重现步骤必填描述如何重现该缺陷预期结果必填描述期望的行为应该是什么样日志/截图必填提供尽可能多的日志或结果信息备注选填补充其他需要提供的信息。在 Issue 评论框中输入/assign或/assign yourself将该 Issue 分配给自己进行处理。场景二文档纠错若发现算子文档描述错误欢迎新建 Issue 进行反馈和修复按社区指引新建Documentation|文档反馈类 Issue 指出对应文档的问题本仓库对应模板为 .gitcode/ISSUE_TEMPLATE/documentation.yml同样在评论框中输入/assign或/assign yourself将 Issue 分配给自己纠正对应文档描述。本仓库文档量大且分层明确API 参考、开发指南、FAQ、错误码参考、日志参考、环境变量等文档纠错时建议先在对应目录内检索相关章节确认错误表述的准确位置与影响范围后再动手。场景三帮助解决他人 Issue如果社区中他人遇到的问题您有合适的解决方法欢迎在 Issue 中发表评论交流帮助他人解决问题和痛点共同优化易用性如果对应 Issue 需要进行代码修改可以在 Issue 评论框中输入/assign或/assign yourself将该 Issue 分配给自己跟踪协助解决问题。五、本地开发工具链pre-commit 检查CONTRIBUTING.md 将 pre-commit 使用方法 列为规范文档之一其作用是“适用于配置 pre-commit并在提交代码前运行格式化与合规检查”。该指导书与本仓库实际配置文件 .pre-commit-config.yaml 对应可验证如下细节。配置的检查项仓库的 .pre-commit-config.yaml 配置了两个 hookHook功能说明clang-formatC/C 代码格式化自动格式化代码保持风格一致OAT Check开源合规检查检测许可证头、禁止二进制文件提交其中 clang-format hook 的具体配置为使用 mirrors-clang-format 的v16.0.0版本作用于c/c类型文件文件后缀覆盖.c .h .cpp .hpp .cc .hh .cxx .hxx通过--stylefile参数遵循项目根目录的.clang-format配置-i表示原地修改明确排除了pkg_inc/profiling/aprof_pub.h以及include/external/acl/下的acl_prof.h、acl_rt*.h、acl_tdt*.h等外部接口头文件——这些文件作为对外 API 头文件格式风格以对外发布版本为准。而 OAT Check 是一个local类型的 hook入口脚本为bash scripts/oat_check.sh见 .pre-commit-config.yaml对提交的文件执行开源合规审计并排除了.pre-commit-config.yaml本身、README.md、Third_Party_Open_Source_Software_List.yaml等已知豁免文件。仓库根目录的 OAT.xml 即 OAT 工具使用的许可证检查规则配置。环境要求Git2.0Python3.8Java17OAT 工具依赖可自动安装clang-format14.0代码格式化Maven3.6OAT 工具依赖可自动安装安装与使用# 1. 安装 pre-commit pip install pre-commit # 或使用系统包管理器 sudo apt install pre-commit # 2. 安装依赖工具Ubuntu/Debian 示例 sudo apt install clang-format openjdk-17-jre maven # 3. 在项目根目录安装 Git Hooks cd /path/to/runtime pre-commit install # 安装成功后显示pre-commit installed at .git/hooks/pre-commit日常提交时每次执行git commit会自动运行检查输出形如clang-format.............................................................Passed OAT Compliance Check.....................................................Passed也可以手动运行# 运行所有检查 pre-commit run # 运行特定类型检查 pre-commit run clang-format pre-commit run oat-check # 检查所有文件不限于暂存区 pre-commit run --all-files紧急情况可跳过检查仅紧急情况下使用正常开发流程应保证检查通过git commit --no-verify -m emergency fixOAT 检查首次运行时会自动检测/安装 Java 17 与 Maven并克隆编译 tools_oat 工具约 1-2 分钟后续提交会使用缓存的 JAR速度很快。OAT 的检查项包括许可证头检查确保源文件包含 CANN License 头、二进制文件检查禁止提交二进制文件、归档文件检查禁止提交 zip/tar 等归档文件。六、代码提交后的 CI 校验本地 pre-commit 通过后PR 进入服务端流水线。从 .gitcode/workflows/PR-pipeline_runtime.yml 可以看到Runtime 的 PR 流水线以阶段stage方式组织例如stage1: PreBuild预构建含测试镜像选择与stage2: Compile编译并配套了 compile_action.yml、staticcheck_action.yml、llt_action.yml 等子流水线预构建、编译、静态检查、LLT 测试。流水线还支持在 PR 评论中输入/compile类指令触发编译见 workflow 的comments: [ ^(?:\/)?compile* ]触发配置配合并发控制concurrency.max: 15超出排队。从源码结构看/assign、/compile等评论指令与 Issue 分配、流水线触发构成了本仓库社区协作的自动化骨架贡献者通过 Issue 认领问题通过 PR 模板声明变更类型与测试方式再由流水线统一把关。七、贡献流程速查清单把 CONTRIBUTING.md 与仓库配套设施串起来一次完整贡献可按以下清单执行定位场景Bug 修复 / 文档纠错 / 帮助他人 Issue选择对应的 Issue 模板见 .gitcode/ISSUE_TEMPLATE/新建 Issue 并用/assign认领方案对齐非简单 bug 修复新增特性/接口/配置/流程改动先在 Issue 中完成方案讨论并按 设计文档模板 输出设计说明编码自检遵守 编码规范改动 UT 时叠加遵守 UT 代码规范 与 UT 用例开发指导涉及错误码/错误文案时参照 Error Message 开发总纲本地检查按 pre-commit 指导 安装 hook提交前确保 clang-format 与 OAT 合规检查全部 Passed提交 PR按 PR 模板 填写描述、变更类型、关联 Issue、测试步骤与核对清单等待 CI预构建/编译/静态检查/LLT通过后进入评审合入。遵循以上流程您的贡献即可在规范、工具链与流程三个层面与 Runtime 仓库保持对齐显著降低代码被拒绝合入的概率。【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
