CANN 社区 GitCode 仓库协作与 PR 合入门禁 FAQfork、分支保护、机器人评论命令与 CI 触发全解【免费下载链接】infrastructure本仓库用于托管CANN社区基础设施团队的公开信息包括不限于会议日程成员信息服务文档和配置等信息项目地址: https://gitcode.com/cann/infrastructureCANN 社区的所有开源仓库均托管于 GitCode并围绕 fork Pull RequestPR 机器人评论 CI 流水线构建了一套完整的协作与合入门禁体系。本文以 CANN 基础设施团队维护的 infra-faqs.md 为核心系统解答开发者在使用 CANN 仓库过程中最常遇到的 6 类问题同名仓库 fork 失败、保护分支与非保护分支、直接 push 与评论合入的区别、评论区机器人命令语义以及 PR 不触发 CI 的处理方法并结合仓库内的机器人能力文档、CI 配置指导与 SDLC 安全规范做源码级纵深说明。读完本文你将能独立完成 CANN 仓库的代码贡献全流程排障并理解社区为什么要求人人走 PR、评审必留痕。一、为什么不能 fork 一个 CANN/abc 仓库到个人账号下1.1 现象与原因在 GitCode 上尝试 fork CANN 组织的仓库例如CANN/abc到个人账号时有时会直接失败。根据 infra-faqs.md 中的官方说明这类问题几乎总是因为个人账号下已经存在同名仓库例如你之前已经从 CANN 组织 fork 过一个名为abc的仓库。根本原因是 GitCode 的仓库寻址机制平台通过个人账号名 仓库名来唯一定位一个仓库。因此同一账号下不允许出现两个同名仓库否则地址会发生冲突平台便拒绝执行 fork 操作。1.2 解决方案进入个人账号下已存在的同名仓库如yourname/abc修改该仓库的名称和/或路径使其与待 fork 的CANN/abc不再重名重新回到CANN/abc仓库页面执行 fork 即可。提示fork 的目的是在个人账号下获得一份可自由修改的副本之后通过提交 PR 的方式将改动贡献回 CANN 主仓。因此 fork 前建议先检查个人仓库列表中是否已有同名仓库避免无谓的反复操作。二、保护分支与非保护分支的区别2.1 核心区别维度保护分支Protected Branch非保护分支Unprotected Branch推送权限可设置特定角色或成员才拥有推送push权限不支持设置符合条件的人员均可推送合并权限可设置特定角色或成员才拥有合并merge权限不支持设置典型用途承载主干代码的master/main等发布分支日常开发、临时分支、大文件中转分支2.2 为什么默认分支必须保护这一点在 CANN 基础设施团队的 社区基础设施软件开发生命周期治理与安全规范V1.04.3 开发编码阶段中被明确为【MUST】 强制要求代码仓库的默认分支必须开启保护机制。禁止包括管理员在内的任何角色直接推送代码。所有变更必须通过 Pull RequestPR发起且需满足人工审核通过与自动化流水线扫描、测试通过双重条件方可合入。其背后的安全逻辑是默认分支承载核心业务逻辑直接推送极易引入未经核实的故障或漏洞通过强制 PR 合入可以利用代码评审拦截缺陷并依托自动化检测屏蔽风险代码同时保证核心代码库的审计记录完整可追溯。三、CANN 开发者角色可以直接 push 代码到社区仓库吗不可以。根据 infra-faqs.md 的明确说明CANN 开发者不允许直接 push 代码到社区仓库只有仓库管理员以及被授权到保护分支的角色才能直接 pushCANN 开发者若想贡献代码只能先 fork 社区仓库到个人账号然后在个人副本上开发最后通过提交 Pull Request 的方式将改动贡献回主仓。这与上一节的分支保护策略是一脉相承的无论贡献者身份如何主干代码的变更都必须经过 PR 流程在评审与自动化门禁双重把关下合入而不是绕过审查直接写入。四、直接 push 代码 vs 评论 /lgtm、/approve 合入代码4.1 两种方式的本质差异对比项git 直接 push评论 /lgtm、/approve 合入审核环节无有至少 1 位 committer 评审合入风险较高较低适用场景文件过大超过个人仓库限制等特殊场景常规代码贡献合入路径先 push 到非保护分支再向保护分支发起 merge通过 PR 机器人评论打标签自动合入4.2 直接 push 的适用场景直接 push 虽然缺少必要的审核环节、存在一定合入风险但社区并未完全禁止其典型应用场景是需要上传的文件过大超过了个人仓库的限制。此时可将大文件先直接 push 到仓库的非保护分支然后再通过非保护分支 → 保护分支的 merge 流程完成合入。4.3 评论合入的评审保证通过评论/lgtm、/approve合入代码从流程上增加了评审环节保证一份代码的合入至少需要提交者以外的一位 committer 的评审同意——即便提交者本人就是 committer也需要另一位 committer 同意才能合入。这背后对应 CANN 社区机器人CANN-robot的完整标签机制详见 docs/robot/robot能力列表.md/lgtm添加代表代码已评审的lgtm标签执行人为仓库所属 SIG 组的 committer/approve添加代表committers 同意合并的approved标签默认采取squash 合并方式执行人为仓库所属 SIG 组的 committers/check-pr检查 PR 中的标签是否满足合入条件满足则自动合并 PR。注意lgtm与approved是两个不同层级的门禁lgtm代表代码评审通过approved代表合并决策通过两者都需要由具备对应权限的 committer 发出评论机器人负责打标签与执行合入动作。五、CANN 社区仓库评论区支持哪些命令CANN 社区中所有项目均由 Bot 维护开发者可以在每个 Pull Request 或 Issue 下通过评论触发 Bot 命令。完整的命令清单参见 CANN社区评论命令一览以下是核心命令速查5.1 PR 合入门禁类命令命令示例使用范围描述面向对象/check-cla/check-claPR强制重新检查 PR 的 CLA 状态已签署则加cann-cla/yes否则加cann-cla/no所有开发者/cla cancel/cla cancelPR强制删除cann-cla/yes标签仓库管理员/compile/compilePR触发编译 CodeArts 流水线通过打ci-pipeline-passed失败打ci-pipeline-failed所有开发者/lgtm/lgtmPR添加代表代码已评审的lgtm标签仓库所属 SIG 组的 committer/lgtm cancel/lgtm cancelPR移除lgtm标签仓库所属 SIG 组的 committer/approve/approvePR添加代表 committers 同意合并的approved标签默认 squash 合并仓库所属 SIG 组的 committers/approve cancel/approve cancelPR移除approved标签仓库所属 SIG 组的 committers/check-pr/check-prPR检查 PR 标签是否满足条件满足则合并 PR任何人/merge/mergePR添加代表 branch_keeper 同意合并的keeper_approved标签仓库对应分支的 branch_keeper5.2 Issue / PR 标签与协作类命令命令示例使用范围描述面向对象/kind **/kind bugPR / Issue添加kind/bug等分类标签标签需已存在于仓库仓库管理员可直接添加其他人评论添加/remove-kind **/remove-kind bugPR / Issue移除kind/bug标签所有人/priority **/priority highPR / Issue添加priority/high等优先级标签仓库管理员可直接添加其他人评论添加/remove-priority **/remove-priority highPR / Issue移除优先级标签所有人/sig **/sig AIPR / Issue添加sig/AI等 SIG 归属标签仓库管理员可直接添加其他人评论添加/remove-sig **/remove-sig AIPR / Issue移除 SIG 标签所有人/assign [[]...]/assign cann-robotIssue为 Issue 指派负责人所有人/unassign [[]...]/unassign cann-robotIssue取消 Issue 指派负责人所有人/label add **/label add bug resolvedPR / Issue添加一个或多个指定标签空格分隔所有人/label remove **/label remove bug resolvedPR / Issue删除一个或多个指定标签空格分隔所有人命令参数规则/kind、/priority、/sig等命令可接受大小写字母、数字、中划线、下划线。需特别注意的是通过评论添加的标签必须已存在于仓库中否则无法打上。5.3 机器人 Issue 自动处理规则除 PR 评论命令外机器人还会对 Issue 做自动化生命周期管理详见 docs/robot/robot能力列表.md相关规则标签名、超时天数、评论模板统一维护在 bot-issue-manage.yaml 配置文件中配置项默认值含义label_resolveresolved标识 Issue 已解决的标签label_stalestale标识 Issue 进入闲置状态的标签label_wait_feedbackwait-feedback标识正在等待 Issue 提交者反馈的标签resolve_to_stale_days7resolved 后允许的最大未更新天数超时自动标记 stalestale_to_close_days14stale 后允许的最大未更新天数超时自动关闭wait_feedback_to_warn_days7wait-feedback 后负责人已回复但提单人未回复超时发预警wait_feedback_to_close_days14预警后提单人继续沉默超时自动关闭stale_comment/wait_feedback_warn_comment/wait_feedback_close_comment见配置文件各阶段机器人自动发布的提示评论模板规则新增与调整步骤为修改 bot-issue-manage.yaml → 提交 PR → PR 合入后机器人配置在每轮任务执行前自动刷新生效。注意确保目标仓库中已存在配置的标签否则机器人可能无法成功执行打标动作。六、提交 PR 后没有触发 CI 构建如何处理这是贡献者最常遇到的问题之一。根据 infra-faqs.mdCI 未及时触发通常有两种情况6.1 情况一webhook 通知延迟或丢失原因网络原因或系统任务调度原因导致从代码仓库发出的 webhook 通知事件没有及时到达目标服务因此没有触发 CI 构建。处理在 PR 评论区评论/compile手动重新触发编译流水线。6.2 情况二CI 构建工程尚未创建原因代码仓库创建后短时间内就提交了 PR此时系统尚未为该仓库创建 CI 构建工程因此触发不到 CI 构建。处理此时评论/compile也不生效请稍等片刻待系统自动完成构建工程创建后再触发。6.3 CI 流水线的触发机制从 CI 配置侧看CANN 仓库的编译流水线正是通过 PR 评论触发的。参考 CI流水线配置指导.md 中的触发配置on: pr_comment: types: [ created ] keyword: ^(?:\/)?compile* pull_request_comment: types: [created] branches: [ * ] comments: [ ^(?:\/)?compile* ]其中pr_comment用于标识预合并pre-merge流水线pull_request_comment的comments字段以正则过滤决定何时启动流水线。这也解释了为什么评论/compile是手动重新触发 CI 的标准入口。6.4 CI 触发后的检查项流水线触发后会按静态检查、编译构建、测试三类执行一系列检查项详见 docs/ci/ci_guide.md任务分类任务项示例说明静态检查codecheck_{xxx}、antiposion_{xxx}、SCA_{xxx}、API_Check、codecheck_precommit等安全类检查敏感信息、代码注入等、恶意文件扫描、开源合规检查、API 兼容性校验、代码规范检查编译构建Compile_{xxx}_X86、Compile_{xxx}_ARMX86 / ARM 平台源码编译、依赖拉取、可执行文件生成单元测试UT_{xxx}核心函数/模块单测通过标准为用例无失败且覆盖率不低于仓库预设阈值系统测试ST_{xxx}基于完整系统部署环境验证多模块协同冒烟测试PreSmoke_{xxx}按芯片型号拆分快速验证核心功能可用性流水线结束后机器人会自动在 PR 评论区写入汇总评论last_comment包含成功/失败明细、失败日志、编译产物、覆盖率/检查报告链接等开发者可据此快速定位问题。若 CI 运行中遇到流水线触发失败、静态检查失败、单元测试覆盖率不足等问题可查阅 CANN社区CI工程FAQ 获取对应解决方案。七、关于机器人评论与 CI 的常见延伸排障以下排障要点来自 docs/robot/robot使用指南.md 与 infra-sdlc-guidelines.md是评论区命令与 CI 门禁配套使用时的常见坑位7.1 评论 /lgtm、/approve 后没有自动打标签核对身份与 ID确认评论人是对应模块的 maintainer / committer并仔细对比评论人的 gitcode-id 与仓库sig-info.yaml中填写的 gitcode-id区分大小写。若 ID 不一致需要提 PR 修改sig-info.yaml合入约 10 分钟后权限生效再重新评论。核对数量一般情况下PR 涉及的每个模块都需要 1 个 committer/maintainer 评论/lgtm和 1 个 committer 评论/approve才能打上标签。核对评论时间若评论时间早于 PR 最新 commit 的时间评论无效常见原因是提交代码机器的时间与实际时间不一致需修正机器时间后回退至上一 commit 重新提交。排除网络波动以上均确认无误仍不打标签时可能是网络波动等待 1 分钟重新评论触发即可。7.2 PR 标签足够却没有自动合入机器人会评论相应的提示信息常见情形包括提示信息原因处理建议Do not meet the condition of Fast-forward Merge, please do the rebase.PR 合并模式要求 fast-forward 条件commits 均基于目标分支最新 commit 提交基于目标分支最新 commit rebase 代码或联系管理员调整 PR 合并模式You do not have permissions to push into target branch机器人账号没有合入该分支 PR 的权限联系管理员授予机器人账号合入对应分支 PR 的权限Failed to squash...PR 代码与目标分支最新代码存在冲突按评论提示解决冲突后重新 pushgit update-ref: exit status 128...同一时间、同一仓库、同一分支另有 PR 正在合入并发等待约 1 分钟后再次评论/check-pr触发合入The MR can not be merged, because of this MR is work in process.PR 标题以[WIP]开头删除标题中的[WIP]CodeReview discussion not resolved.PR 存在未解决的评审意见先解决全部评审意见The following labels are not ready...非机器人账号添加的标签无效先移除手动打的标签再评论对应指令让机器人重新打标7.3 与合入门禁相关的安全底线CANN 基础设施团队将代码合入门禁写入了 社区基础设施软件开发生命周期治理与安全规范V1.0其中与 PR 流程强相关的【MUST】 项包括默认分支必须保护禁止任何角色直接推送、贡献者必须签署 CLA、CI/CD 流水线必须集成 SAST 静态安全扫描与密钥扫描PR 阶段实时增量扫描 全量分支周期性扫描识别到硬编码凭证自动阻断合入。这也从治理层面解释了直接 push 不可取、评论合入是正道的根本原因。八、遇到问题如何寻求支撑当 FAQ 未覆盖你的问题、或流水线/机器人出现异常时可按以下渠道求助详见 docs/services.md基础设施支撑矩阵覆盖新建流水线、CLA 签署、CANN-robot、社区邮件列表、社区会议、漏洞管理服务、CANN 数字化协作平台、静态检查、AI 技能门禁 CI 排障等支撑项每项均列出了对应的 GITCODE 账号与邮箱可直接联系对应支撑人组件仓库 CIE 支撑矩阵遇到编译构建异常、UT 执行异常、冒烟测试任务异常、静态检查结果屏蔽审核、代码合入异常等问题时优先联系对应组件仓库的 CIE持续集成工程师处理。结语CANN 社区的仓库协作体系可概括为一条主线fork 个人副本 → 开发 → 提交 PR → 评论/compile触发 CI → 评论/lgtm、/approve完成评审 → 标签齐备后由机器人自动合入。理解 infra-faqs.md 中的 6 个高频问题再配合 机器人命令一览、CI 工程检查项 与 SDLC 安全规范 使用即可顺畅完成从提码到合入的完整闭环并在遇到门禁异常时快速自助定位。【免费下载链接】infrastructure本仓库用于托管CANN社区基础设施团队的公开信息包括不限于会议日程成员信息服务文档和配置等信息项目地址: https://gitcode.com/cann/infrastructure创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考