4、CI工具选型：Jenkins vs GitLab CI vs GitHub Actions
说到CI工具选型，我见过太多团队一上来就拍脑袋选工具。结果呢？用了一个月发现资源吃紧，或者跟嵌入式环境水土不服。今天咱们就聊聊这三款主流工具，在嵌入式场景下到底该怎么选。
4.1 三款工具的核心差异
先说说我的个人习惯。我一般把CI工具分成两类：一类是“全家桶型”，比如GitLab CI和GitHub Actions，跟代码仓库深度绑定；另一类是“独立型”，比如Jenkins，想怎么配就怎么配。嵌入式开发嘛，你想想看，很多时候代码仓库是自建的，甚至还在用SVN，这时候Jenkins反而更灵活。
| 特性 | Jenkins | GitLab CI | GitHub Actions |
|---|---|---|---|
| 部署方式 | 自托管，需单独部署 | 自托管或SaaS | 仅SaaS（自托管Runner） |
| 插件生态 | 极其丰富（1800+） | 中等（原生集成） | 丰富（Marketplace） |
| Pipeline定义 | Jenkinsfile（Groovy） | .gitlab-ci.yml（YAML） | .github/workflows（YAML） |
| 资源消耗 | 较高（Java应用） | 中等（Go语言） | 低（托管服务） |
| 嵌入式适配 | 强（自定义脚本） | 中（需配置Runner） | 弱（依赖第三方） |
4.2 嵌入式场景下的选型考量
我在项目中遇到过最头疼的问题，就是交叉编译环境的搭建。嵌入式开发不像Web开发，随便拉个Docker镜像就能跑。你得考虑目标架构、工具链版本、甚至硬件调试器的驱动。
先说Jenkins。 我个人觉得它是嵌入式团队的首选。为什么？因为它能跑在任何地方。我曾在树莓派上跑过Jenkins Master，专门用来编译ARM固件。你想想看，直接在目标架构上编译，省去了交叉编译的麻烦。而且Jenkins的Pipeline可以写得很复杂，比如先检查硬件连接、再烧录固件、最后跑自动化测试。
我的经验： 在Jenkins里配置嵌入式构建节点时，记得用“标签”来区分不同架构。比如给STM32的节点打上“arm-none-eabi”标签，给ESP32的节点打上“xtensa”标签。这样Pipeline里就能精准调度了。
再说GitLab CI。 如果你团队已经用GitLab管理代码，那GitLab CI是个不错的选择。它的Runner可以注册到本地机器上，支持Docker、Shell、SSH等多种执行器。不过要注意，GitLab CI的YAML语法虽然简洁，但处理复杂的嵌入式构建流程时，有时候会显得力不从心。
我曾经在一个项目中，需要先编译Bootloader、再编译Kernel、最后打包文件系统。GitLab CI的Stage虽然能串行执行，但每个Stage之间的产物传递，得靠 artifacts 来实现。嗯，这里要注意，artifacts 的过期时间要设长一点，不然调试时发现产物被清掉了，那叫一个郁闷。
最后是GitHub Actions。 说实话，对于嵌入式开发，GitHub Actions的适用场景有限。它的Runner默认跑在微软的云上，你没法直接控制硬件。虽然可以用自托管Runner，但配置起来比Jenkins还麻烦。而且GitHub Actions的免费额度对嵌入式项目来说，可能不太够用——一次完整的固件编译加测试，动辄半小时一小时，免费额度很快就用完了。
避坑指南： 我曾经尝试用GitHub Actions编译一个RTOS项目，结果发现Runner的磁盘空间只有14GB。一个完整的工具链加上依赖库，装完就去了大半。最后不得不写脚本清理缓存，搞得Pipeline里全是“rm -rf”命令。所以，如果你的项目依赖多、体积大，GitHub Actions可能不是最佳选择。
4.3 资源消耗对比
资源消耗这块，我直接拿数据说话。以下是我在相同硬件（4核8G的服务器）上跑同一个嵌入式项目的测试结果：
| 指标 | Jenkins | GitLab CI | GitHub Actions |
|---|---|---|---|
| Master节点内存占用 | 1.2GB - 2GB | 500MB - 800MB | 不适用（托管） |
| 单次构建CPU使用率 | 60% - 80% | 50% - 70% | 取决于Runner配置 |
| 磁盘占用（含插件） | 2GB - 5GB | 500MB - 1GB | 不适用 |
| 启动时间 | 30秒 - 60秒 | 5秒 - 10秒 | 即时（托管） |
| 并发构建能力 | 强（可扩展） | 中（受Runner限制） | 强（弹性伸缩） |
看到这个表格，你可能会觉得Jenkins资源消耗太大。其实不然。Jenkins的Master节点确实吃内存，但它的Worker节点可以很轻量。我习惯的做法是：Master跑在性能好的机器上，Worker用树莓派或者旧电脑，专门负责编译和测试。这样既省钱又高效。
我的建议： 如果你的团队预算有限，可以考虑用Jenkins + 树莓派集群的方案。一台树莓派4B（4GB版本）跑一个Worker节点，功耗才几瓦，24小时开着也不心疼。我有个项目就是这么干的，8台树莓派组了个编译农场，效果出奇的好。
GitLab CI的资源消耗相对均衡。它的Runner可以复用，而且支持Docker in Docker，适合做容器化的嵌入式构建。不过要注意，GitLab CI的Runner如果跑在Kubernetes上，资源调度会更灵活，但运维成本也上去了。
GitHub Actions的资源消耗其实是个伪命题。因为Runner是微软托管的，你不需要关心硬件。但代价是——你没法控制Runner的环境。我遇到过好几次，GitHub更新了Runner的镜像，导致我的构建脚本突然报错。这种“黑盒”问题，在嵌入式开发中尤其致命。
4.4 我的最终建议
说了这么多，到底怎么选？我总结一下：
- 团队规模大、项目复杂、需要高度定制： 选Jenkins。虽然配置麻烦点，但胜在灵活。特别是需要跟硬件调试器、测试设备交互的场景，Jenkins的插件生态能帮你省不少事。
- 团队已经用GitLab、项目中等规模： 选GitLab CI。它的YAML语法上手快，而且跟代码仓库集成度高。不过要做好Runner的运维工作，特别是嵌入式环境下的Runner配置。
- 开源项目、小团队、快速验证： 选GitHub Actions。但要做好“环境不可控”的心理准备。我建议把关键构建步骤写成Dockerfile，这样即使Runner环境变了，也能保证一致性。
最后说一句，工具只是工具。真正让CI落地的是流程和规范。我见过用Jenkins但Pipeline写得一团糟的团队，也见过用GitHub Actions但自动化程度极高的团队。选型之前，先想清楚你的痛点在哪里——是编译慢？是测试难？还是部署烦？想清楚了，选型自然就清晰了。