仓库贡献准入规则：CLA 协议签署与 /compile 构建校验操作规范
CLA签署 + /compile构建 全解析（PR提交配套自动化校验）
一、CLA 签署是什么
1. 全称
CLA = Contributor License Agreement 贡献者许可协议
2. 作用
开源/企业代码仓库强制协议：
你向项目提交代码、设计文档、配置文件（通过PR）前，必须线上签署一份协议，约定：
- 你提交的内容（代码/文档/图片）版权归项目/公司所有；
- 保证提交内容无侵权、无抄袭、无涉密内容；
- 允许项目方免费使用、修改、分发你的提交内容。
3. PR场景规则
- 首次提交PR，仓库机器人会自动评论一条签署链接；
- 点开链接登录账号（GitHub/Gitee/GitLab账号）勾选同意，完成签署；
- 没签CLA的PR会被拦截合并，评审、CI流水线都无法正常放行；
- 一般一次签署长期生效，后续提交PR不用重复签。
区分：CLA和普通保密协议NDA
- NDA：对内保密；
- CLA：对外开源/内部共建项目的版权授权，提交代码/文档准入门槛。
二、/compile 构建是什么
1. 含义
/compile 是仓库CI自动化流水线的触发指令 （评论指令）
compile直译：编译、构建，指自动化打包、校验、渲染流程。
2. 完整流程
PR创建后，不会自动跑完整构建，需要手动在PR评论区输入指令：
/compile回车发送，触发后端流水线自动执行一系列检查：
- 文档校验：如果是设计文档（md/图片）：格式规范、图片链接、目录结构、语法错误检查；
- 代码编译：如果有代码，编译源码、检查语法报错；
- 产物构建：生成静态文档站点、PDF、页面预览包；
- 规范扫描：命名规范、注释、目录结构是否符合团队要求；
- 产出报告：流水线完成后自动在PR下回复结果：成功/报错清单。
3. 为什么必须执行
- 只有
/compile构建全部通过，PR才允许评审、合并； - 构建失败代表你的文档/代码有问题（结构缺失、格式错乱、图片失效、编译报错），需要修改后重新执行
/compile。
三、结合你的PR流程：完整操作顺序（从提交PR到合并）
- 上传文档/代码，创建PR（Pull Request）；
- 检查机器人消息，完成 CLA签署（不签直接锁死PR）；
- 在PR评论框输入
/compile发送，触发自动化构建； - 等待CI流水线跑完，确认构建全部绿灯通过；
- 再交给同事做人工评审（对应你上一句"PR提交评审"）；
- 评审无意见、CI全绿，才能合并到主干分支。
四、常见失败场景
CLA失败
- 未点击链接签署；账号登录不一致（提交代码的账号≠签署账号）；企业账号权限未同步。
/compile 构建失败
- 设计文档没搭好目录结构（和你上一句"必须进行结构搭建"对应，结构缺失会直接构建报错）；
- 图片路径错误、附件缺失；
- Markdown语法错乱、标题层级混乱；
- 代码存在编译报错、依赖缺失；
- 文件命名、存放目录不符合仓库规范。
五、通俗总结
- CLA签署 = 入场门票：证明你有权贡献内容，版权合规，不签不让走后续流程；
- /compile构建 = 自动化质检打包 ：机器自动检查你的设计文档/代码有没有格式、结构、编译问题，质检合格才能找人人工评审。
两者都是PR提交后硬性前置操作，缺一不可。
CLA签署, 需要 ，设置开源协议吗
分两种场景：要不要设置开源协议，取决于你的项目是否要开源、CLA 用途
一、先分清两个东西：CLA ≠ 开源协议
- CLA（贡献者协议）
管「别人往你项目提交代码/文档时的版权授权」，对内私有仓库、对外开源仓库都能用。 - 开源协议（LICENSE）
管「项目本身对外怎么复制、修改、商用分发」，只有对外公开开源才必须配置；纯企业内部私有项目不用。
二、场景1：项目纯内部私有（公司自用，不对外公开）
不需要设置开源 LICENSE 文件
- 仓库仅公司内网/企业Gitee/Gitlab，外部人看不到代码、设计文档；
- 你们要求签署 CLA 只是内部版权约束：防止员工提交涉密、第三方侵权内容，约定公司拥有所有产出版权；
- 操作：只保留 CLA 签署流程，根目录不用放 MIT/Apache/GPL 等开源协议文件。
三、场景2：项目对外开源（公开到 GitHub/Gitee，任何人可拉取下载）
必须配置开源协议 LICENSE，且 CLA 配套使用
- 法律强制：没有开源协议时，默认保留作者全部版权，他人不能复制、修改、商用，等于"名义开源实际闭源"；
- CLA 配合开源协议的作用：
开源协议规定外部使用者权限，CLA 规定贡献者提交内容的版权归属 ，避免后续代码版权纠纷；
比如 Apache2.0 开源项目，几乎都会配套 Apache CLA。 - 常用开源协议推荐
- 宽松商用无限制：MIT、Apache 2.0（推荐企业开源项目，允许商用、闭源二次开发）
- 传染性开源：GPL（修改分发后必须全部开源，商用约束极强）
四、特殊情况：内部项目但未来计划开源
建议提前两步准备
- 仓库根目录提前新建
LICENSE文件，选定后续要用的开源协议； - 保留现有 CLA 签署流程，统一所有历史提交的版权授权，后续开源不用补签历史贡献者。
五、结合你之前的 PR 流程总结
- 仅公司内部使用、不对外公开：不用设置开源协议，只维持 CLA 签署 + /compile 构建校验即可；
- 代码/设计文档对外公开、允许外部人下载使用：必须添加开源 LICENSE 文件，CLA 作为提交前置流程保留；
- CLA 签署是独立要求，和是否开源没有绑定关系，私有仓库也完全可以启用 CLA。
补充小提示
- CLA 是提交PR时的准入校验（人提交前签）；
- LICENSE 是仓库根目录静态文件（所有人查看项目时可见）；
- 二者功能不冲突，可以单独存在，也可以搭配使用。