CANN 社区贡献基础设施 FAQ 实战指南CLA 签署、PR 门禁与 Bot 命令合入全解析【免费下载链接】sip本项目是CANN提供的一款高效、可靠的高性能信号处理算子加速库基于华为Ascend AI处理器专门为信号处理领域而设计。项目地址: https://gitcode.com/cann/sip本指南以 CANN 开放社区SiP 信号处理加速库所属社区的贡献基础设施 FAQ 为主体系统讲解从提交 Pull Request 到代码合入全过程中最常遇到的七个问题cann-cla/no红色标签如何处理、fork 同名仓库冲突、保护分支与推送权限、/lgtm与/approve合入机制、评论区 Bot 命令含义以及 CI 未触发的排查方法。读完本文你将能独立走通签署 CLA → 提交 PR → 触发 CI → 评审合入的完整贡献链路并理解其背后的分支策略与门禁逻辑。上图展示了 CANN 社区 PR/Issue 从提交到合入的 Bot 交互主流程提交 Issue/PR 后依次经过 CLA 协议检查、流水线触发、评审人评审、合入条件检查等环节每个环节都有对应的评论命令与标签图片位于 docs/zh/API_Reference/figures/docs_images_robot.png。引言Bot 驱动的 CANN 社区协作模式CANN 社区中所有项目包括本仓库 cann/sip均由 Bot 维护开发者可以在每个 Pull Request 或 Issue 下方通过评论触发 Bot 命令从而完成 CLA 检查、编译流水线、代码评审、合入等操作具体交互命令可参见 CANN社区评论命令一览。这种评论即操作的模式带来两个直接后果评论内容是流程的输入/check-cla、/compile、/lgtm、/approve、/merge等命令会改变 PR 的标签状态进而决定 PR 是否具备合入条件标签是流程的状态cann-cla/yes、ci-pipeline-passed、lgtm、approved、keeper_approved等标签共同构成合入门禁。理解这套机制是解决下文七个高频问题的前提。以下 FAQ 原文位于 docs/zh/context/infra-faqs.md。1. 提交 PR 后出现 cann-cla/no 红色标签如何处理标签含义出现cann-cla/no表示该 PR 所包含的 commit 中有部分贡献者没有签署 CANN 社区的贡献者协议CLA。签署地址可以在 PR 评论区找到。根据贡献身份有三种签署方式个人名义贡献选择签署个人 CLA企业名义贡献选择签署法人 CLA已签署企业 CLA 的企业员工名义贡献选择法人贡献者登记。签署后会收到主题为Signing CLA on project of xx的邮件需联系邮件内容中的 Corporation Managers 进行审批审批通过后在 PR 评论区评论/check-cla重新触发 CLA 检查即可将标签更新为cann-cla/yes。1.1 CLA 检查的凭证committer 邮箱CLA 检查是使用 commit 信息中的 committer 邮箱作为检查凭证的该邮箱可以通过以下命令查询git log --prettyfuller因此签署 CLA 所用的邮箱必须与 commit 邮箱一致否则检查无法通过。针对邮箱不一致的场景infra-faqs.md 给出了完整的处理对照表场景选择处理方案commit 邮箱和 Gitcode 提交邮箱一致统一用该邮箱使用该邮箱直接在上述签署地址签署 CLA 即可commit 邮箱和 Gitcode 提交邮箱不一致希望使用 commit 邮箱签署修改 Gitcode 提交邮箱为 commit 邮箱在 Gitcode 个人设置页面添加 commit 邮箱并设置为提交邮箱然后在上述签署地址完成 CLA 签署即可commit 邮箱和 Gitcode 提交邮箱不一致希望使用 Gitcode 提交邮箱签署在 git 运行的本地通过执行命令git config --global user.name ****和git config --global user.email ****可修改 git 的 commit 邮箱信息为 Gitcode 的提交邮箱完成后再进入签署地址进行 CLA 签署1.2 与贡献指南中的 CLA 类型对应关系贡献指南 对 CLA 类型做了更细致的划分法人 CLA以企业身份参与一般由企业管理人员签署、法人贡献者 CLA已签署法人 CLA 企业的员工申请需企业管理员审批、个人 CLA非企业员工个人身份以及企业管理员 CLA有权对法人贡献者 CLA 的申请进行审批和人员管理。FAQ 中的三种选择正是前三种常见身份对应的操作入口若你担任企业管理员还可额外签署企业管理员 CLA 以承担审批职责。1.3 强制复查与撤销命令在 infra-command.md 的命令表中与 CLA 相关的还有两条命令/check-claPull Request所有开发者所有仓库强制重新检查 PR 的 CLA 状态。若提交者已签署 CLA则添加cann-cla/yes标签否则添加cann-cla/no标签/cla cancelPull Request仓库管理员所有仓库强制删除cann-cla/yes标签。2. 为什么不能将 CANN/abc 仓库 fork 到个人账号下该问题通常是因为个人账号下已经存在名为abc的同名仓库例如之前已从 CANN 组织下 fork 过名为abc的仓库。Gitcode 通过个人账号 仓库名寻址因此不允许个人账号下出现同名仓库。解决方法先修改个人账户下已有仓库的名称和路径然后再从CANN/abc仓库执行 fork 操作。这一限制对所有 CANN 组织仓库包括本仓库 cann/sip一视同仁。fork 之前建议先检查个人账号下是否已有同名仓库避免提交 PR 时才发现冲突。3. 保护分支和非保护分支的区别保护分支可以设置特定的角色或成员拥有该分支的推送权限和合并权限非保护分支不支持上述权限控制任何具备推送权限的成员均可直接推送。在本仓库中master等主干分支通常作为保护分支而贡献者的个人 fork 分支或仓库内的临时分支则属于非保护分支两者的权限模型决定了贡献代码必须走 PR 流程详见下文第 4、5 节。4. CANN 开发者可以直接 push 代码到仓库吗不可以。CANN 开发者不允许直接向社区仓库推送代码只有仓库管理员可以向社区仓库推送代码。如果 CANN 开发者想要贡献代码只能将社区仓库 fork 到个人账号下在个人仓库完成代码修改通过提交 Pull Request 的方式将代码贡献回社区仓库。5. 直接 push 代码和通过评论 /lgtm、/approve 合入代码有何区别两者的核心区别在于是否经过评审环节通过 git 命令直接 push缺少必要的审核环节存在一定合入风险。其主要应用场景是当需要上传的文件过大、超过个人仓库限制时只能通过直接 push 到仓库的非保护分支再通过非保护分支向保护分支 merge通过评论/lgtm、/approve合入从流程上增加了评审环节保证一份代码的合入至少需要提交者以外的一位 committer 的评审同意即便提交者本人是 committer也需要另一位 committer 同意。从源码仓库的权限结构可以印证这一点本仓库根目录的 OWNERS 文件第 1-8 行为approvers列表、第 10-17 行为reviewers列表明确列出了拥有评审与批准权限的成员名单/lgtm与/approve命令只有这些角色触发生效approvers: - east_yang - luowen203_gg123 - kerten - demoauguste - zhajianqing123 - renruhai - liujie12345678 reviewers: - east_yang - luowen203_gg123 - kerten - demoauguste - zhajianqing123 - renruhai - liujie123456786. CANN 社区仓库评论区都支持哪些命令CANN 社区仓库评论区支持的命令一览请参见 CANN社区评论命令一览其中与 PR 合入流程和 Issue 管理相关的命令整理如下命令示例使用范围描述面向对象使用仓库/check-cla/check-claPull Request强制重新检查 PR 的 CLA 状态已签署则添加cann-cla/yes否则添加cann-cla/no所有开发者所有仓库/cla cancel/cla cancelPull Request强制删除cann-cla/yes标签仓库管理员所有仓库/compile/compilePull Request触发编译 CodeArts 流水线通过后打ci-pipeline-passed标签失败则打ci-pipeline-failed标签所有开发者所有仓库/lgtm/lgtmPull Request添加代表代码已经评审过的lgtm标签仓库所属 sig 组的 reviewers所有仓库/lgtm cancel/lgtm cancelPull Request移除lgtm标签仓库所属 sig 组的 reviewers所有仓库/approve/approvePull Request添加代表 committers 同意合并的approved标签仓库所属 sig 组的 committers所有仓库/approve cancel/approve cancelPull Request移除approved标签仓库所属 sig 组的 committers所有仓库/check-pr/check-prPull Request检查 PR 中的标签是否满足条件若满足则合并 PR任何人所有仓库/merge/mergePull Request添加代表 branch_keeper 同意合并的keeper_approved标签仓库对应分支的 branch_keeper所有仓库/kind **/kind bugPull Request、Issue添加kind/bug等标签**可接受大小写字母、数字、中划线、下划线下述**规则通用仓库管理员可直接添加其他人可评论添加前提是仓库中存在该标签所有仓库/remove-kind **/remove-kind bugPull Request、Issue移除kind/bug等标签所有人所有仓库/priority **/priority highPull Request、Issue添加priority/high等标签仓库管理员可直接添加其他人可评论添加前提是仓库中存在该标签所有仓库/remove-priority **/remove-priority highPull Request、Issue移除priority/high等标签所有人所有仓库/sig **/sig AIPull Request、Issue添加sig/AI等标签仓库管理员可直接添加其他人可评论添加前提是仓库中存在该标签所有仓库/remove-sig **/remove-sig AIPull Request、Issue移除sig/AI等标签所有人所有仓库/assign [[]...]/assign、/assign cann-robotIssue为 Issue 指派一位负责人所有人所有仓库/unassign [[]...]/unassign、/unassign cann-robotIssue取消 Issue 指派的负责人所有人所有仓库6.1 命令使用要点标签驱动合入一次完整的 PR 合入通常需要依次满足 CLA 检查cann-cla/yes、编译流水线ci-pipeline-passed、代码评审lgtm、committer 批准approved必要时还需 branch_keeper 的keeper_approved最终由/check-pr汇总检查标签并执行合并角色权限分离reviewers评审、committers批准、branch_keeper分支合并三类角色分别对应不同的命令与 OWNERS 文件中的角色定义一一对应自定义标签需先存在/kind、/priority、/sig等命令通过评论添加标签时要求仓库中必须已存在该标签否则无法添加上。7. 提交 PR 后未触发 CI 构建的原因及处理方法CI持续集成未及时触发通常有两种情况第一种网络原因或系统任务调度原因。从代码仓库发出的 webhook 通知事件没有及时到达目标服务因此没有触发 CI 构建。这种情况可以在 PR 评论中输入/compile重新触发第二种仓库创建后短时间内提交 PR。此时 Jenkins 服务器侧尚未创建 CI 构建工程触发不到 CI 构建此时评论/compile也不生效需要稍等系统自动构建工程。7.1 CI 门禁在仓库侧的体现本地 OAT 合规检查除了 CI 构建CANN 仓库还通过预提交钩子进行开源合规检查。以本仓库的 scripts/oat_check.sh 为例它在本地git commit前对暂存文件执行 OATOpen Source Audit Tool扫描检查Invalid File Type非法文件类型与License Header InvalidLicense 头缺失两类问题若发现问题则输出详细报告并阻止本次提交对应脚本第 251-268 行的提交拦截逻辑可通过git commit --no-verify跳过。这意味着即使 CI 侧流水线正常触发若提交的源码缺少 贡献指南 要求的 License 文件头声明本地合规检查就会先行失败贡献指南要求新建的 cpp、cc、h 等源码文件头部增加 CANN Open Software License Agreement Version 2.0 的版权声明py、sh 等文件则使用#注释形式声明第一行的[Name of the copyright owner]需根据个人或雇主版权归属替换为对应署名年份按创建/修改文件的实际年份填写。因此在向 PR 评论/compile之前建议先在本地完成合规与编译自检减少门禁往返。从 FAQ 到一次完整的贡献流程串联与仓库验证将上述 FAQ 串联起来一次标准的代码贡献流程如下对应 贡献指南 中的代码下载与贡献流程发现问题并建 Issue发现算子 bug、算子优化需求、文档错误或想贡献新算子时先在仓库新建Bug-Report|缺陷反馈、Requirement|需求建议或Documentation|文档反馈类 Issue并通过评论/assign或/assign yourself将 Issue 分配给自己签署 CLA根据身份选择个人 CLA、法人 CLA 或法人贡献者登记对应 FAQ 第 1 节fork 并克隆将社区仓库 fork 到个人账号注意避开同名仓库冲突对应 FAQ 第 2 节再克隆到本地git clone https://gitcode.com/cann/sip.git本地修改与验证在本地分支修改代码添加 License 头声明运行合规检查与编译验证对应 FAQ 第 7 节的门禁前置自检提交 PR 并评论/compilePR 提交后评论/compile触发编译流水线等待ci-pipeline-passed标签评审与合入门禁通过后 PR 会被分配给 committer 检视评审通过后添加lgtm、approved标签最终由/check-pr汇总标签完成合入并自动关闭关联 Issue对应 FAQ 第 5、6 节。上图完整描绘了从发现需求BUG、算子优化、文档纠错、新增算子到代码合入的贡献链路其中门禁通过与代码检视通过两个判断节点正是 FAQ 第 5、7 节讨论的评审与 CI 环节图片位于 docs/zh/API_Reference/figures/docs_images_contrib-flow.png。结语CANN 社区的贡献基础设施围绕Bot 评论命令 标签构建CLA 检查以 commit 邮箱为凭证、编译流水线以/compile触发、合入由 reviewers/committers/branch_keeper 多角色把关再辅以本地 OAT 合规门禁共同保证合入代码的质量与合规性。无论是向 cann/sip 贡献算子、修复 bug 还是纠正文档掌握 infra-faqs.md 中这些问题背后的规则都能显著减少门禁往返让贡献流程更加顺畅。若在贡献过程中遇到其他问题还可随时查阅 CANN社区评论命令一览 与 贡献指南。【免费下载链接】sip本项目是CANN提供的一款高效、可靠的高性能信号处理算子加速库基于华为Ascend AI处理器专门为信号处理领域而设计。项目地址: https://gitcode.com/cann/sip创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考