回滚到 Jenkins

我要的是管用。我想你可能误解了我对「管用」的定义。

离开 Drone CI

在之前，我决定使用 Drone CI 来完成 CI/CD 工作。这是因为在我上学的时候，我们社团的 dalao 选择了使用 Drone CI. 没错，很多时候技术决策真的不一定是下场比较各种指标，而只是单纯地因为「别人在用所以我也要跟着用」。

但是自从上一次和 Drone CI 的缓存机制搏斗之后，我就觉得这个东西多少有点问题了。当然这可以认为是因为我对于容器管理理解薄弱导致的。但是现在我又遇到了一个绝世难题：

如果你为 Drone Runner 指定了标签，那么只有完全匹配该标签的任务才会被调度到这个 Runner 上。哪怕你指定其中一个子集也不行。如果你给所有的 Runner 都指定了标签，那么没有标签的任务将不会被调度到任何 Runner 上。这个「特性」我实在是找不到任何可以开脱的理由，而且考虑到标签的键值对并不支持通配符，我觉得这个决策多少有点恶心人的意味在里面。一个本来可以用于标记 Runner 特征的功能，现在变得鸡肋无比。

再来谈谈这个多 Runner 结构。Drone CI 貌似压根没有提供任何方式来在服务器上查询有多少个 Runner 连接到了服务器。我也不知道 Runner 到底配置了哪些标签。无论是从后台 UI 界面来看还是从 API 来看，似乎获知一个 Drone CI 实例上的 Runner 是压根干不到的事情。这可能是因为 Drone CI 在设计的时候是要求每个 Runner 不停地轮询来检查是否有可执行的任务，而不是统一由核心来调度——但是，讲真，即使是轮询，也能整理一份 Runner 列表以供参考吧！

Drone CI 虽然并不想让你使用标签来向 Runner 来指派任务，它却要求你能够准确地说出 Runner 的实现形式——比如它是一个 Docker Runner, 一个 Exec Runner, 亦或是某种其他类型的 Runner. 在本来就没法查看系统里有多少配置好了的 Runner 的情况下，再需要额外地有这层套路着实让我觉得这玩意没有想要配合我的意思。

多说无益。Harness, 你丫的广告可以收收味了。

迁移到 Jenkins

Jenkins 的迁移其实很简单：安装 Jenkins, 编写 Jenkinsfile, 然后添加项目。第三步甚至可以通过各种神奇的插件 + 组织文件夹来自动扫描和创建；比如 Gitea 集成插件就可以做到自动扫描组织内的全部项目并自动创建项目。

Jenkinsfile 的格式相比于 Drone CI 使用的 YAML 好不到哪去——但它的内核至少是 Groovy 脚本。虽然 Groovy 本身也有点稀碎，加上 Jenkins 的一些魔改看起来更是奇怪，但是相比于 YAML 的各种鬼畜点，这点稀碎我个人还是可以接受的。

我并不打算把所有的东西都迁移到 Jenkins. 那些之前在 Drone CI 上可以正常运行的项目就保持在 Drone CI 上比较好。

It's Normal and It Works

我又想起了这句话。这句经典名言：它没啥毛病，而且它管用。

没错，Jenkins 已经很老了，而且 Jenkins 里面的一堆插件也不再活跃开发。你有很多理由劝我离开 Jenkins, 比如你认为 CI 和 CD 必须分开执行；Jenkins 是在 Docker 出生前诞生的，所以没有「原生支持容器」。Jenkins 的界面「太丑太难用」，不符合现代审美。

说实话，我的答案是：我不愿意花费额外的计算资源来搞你这什么「云原生」，我不关心什么 Reproducible Build, 我的网络磁盘和 CPU 都是要花钱的，我必须节省这些资源。所以，我要有状态的构建，我要上下文保持，我要这货的 Workspace 是持久化的，我要能看到每一个已经配置好的节点和它们的状态，我要有一个中心化的服务器，我要我能够自己操心每个节点的隔离与安全。你大可以嘲讽我没有经历过大项目，没有 Epic Deployment 的经历，盲目地使用状态而看不到这样做的后果。但是我仍然要强调：对于我的需求而言，It's Normal and It Works. 我不想再花费时间在虚拟机里的 Windows 下的 Docker 容器里面想办法让 CMake 叫 MSBuild 能够带着 MSVC 跑起来而且能拽着 vcpkg 一起动而且再给这玩意写缓存——分析镜像内部的挂载路径永远是最有乐趣的事情之一（而且这个缓存系统还有没法解决的 bug）。

我要的是「管用」。我想你可能误解了什么叫「管用」。