CircleCI Orb 构建器

要解决什么问题

在多个项目之间复用 CI/CD 配置是常见需求。团队通常会在多个仓库中反复编写类似的 Docker 构建步骤、环境准备脚本和通用 job 模板。CircleCI Orbs 是官方提供的复用机制，可以把 commands、executors 和 jobs 打包成可发布、可版本化的单元，供多个 pipeline 引用。

但自己从零搭建一个 orb 并不简单：要理解 orb 的目录结构，要设计一套用于验证和发布的 CI 流水线，还要维护版本号的递增逻辑。这个技能把这几件事串成一条自动化的流程。

技能如何工作

核心能力包括：

• 基于 Orb SDK 的脚手架：生成 orb 的目录骨架，包括 src/ 下的 commands、executors 和 jobs 定义文件，以及 orb.yml 清单。
• 流水线驱动的验证与打包：通过 circleci/orb-tools@12 流水线执行校验、打包（pack）等步骤，把 orb 源码转换为可发布的工件。
• 自动化语义化版本管理：通过 CircleCI CLI 在发布时按 SemVer 规则递增版本号，避免手工改版本号带来的冲突。

典型流程大致如下：

1. 用 SDK 初始化 orb 结构，按用途拆分 commands、executors、jobs；
2. 在本地编写并测试各组件；
3. 由 orb-tools 流水线执行校验与打包；
4. 通过 CLI 触发带语义化版本号的发布。

适用边界与注意点

• 需要本地安装 CircleCI CLI 并登录，发布时需要对目标 orb 仓库或 registry 有写权限。
• circleci/orb-tools@12 锁定在特定主版本，其它版本的行为可能不同，接入前应确认与现有 CI 配置兼容。
• orb 一旦发布，后续修改受语义化版本约束：破坏性变更必须升主版本号，否则下游引用会出错。
• 技能负责搭建并自动化 orb 的构建与发布流程，不替代 orb 内部业务逻辑的设计，commands 和 jobs 的参数仍需按项目实际情况完成。