我对 GitHub Actions 痛恨至深

Source: Dev.to

我无法用言语表达我有多讨厌 GitHub Actions。我甚至不记得自己曾经讨厌过使用过的其他技术。诚然，我仍然会取笑我在 PHP 4 时代记得的 PHP¹，但即便如此，我也并没有讨厌它——我只是觉得它相较于 Ruby on Rails 或 Django 等新兴框架稍显逊色。而我却真的讨厌 GitHub Actions。

带着激情²。

Source: …

通往地狱之路

在写下这些文字的前一天，我正在为我的 tmplr 项目实现 build.rs。为了省去你点开的时间——它是一个文件/项目脚手架工具，使用人类可读（且可手工编辑）的模板文件。我（个人）经常使用它，因为手动或借助该工具创建新模板非常容易，所以如果你需要类似的实用工具，去看看吧。

build.rs 使用 CUE 来生成 README.md、CHANGELOG.md 和一个版本/帮助文件，以确保一致性。这件事很有趣；我花了大约 1.5 小时完成，还为此 写了一篇文章——给自己和后代留档。

我对结果很满意，却没有检查 CI 输出，结果自然是失败了。我在 build.rs 中使用了 cue 二进制文件，没有它构建根本无法进行。第二天醒来看到 CI 发来的邮件提醒构建失败，我立刻知道今天不会是充满小狗和彩虹的一天。

我尝试了几次搜索并推送一个能够安装 CUE 的 GitHub Action，结果却得到了最糟糕的结果：矩阵中的一个系统构建失败。

解释一下

我正在为四个平台构建 tmplr：

• Linux ARM
• macOS ARM
• Linux x86_64
• macOS x86_64

很合理，对吧？即使我的用户基数可以用一只没有手臂、另一只装有钩子的海盗的手指来数，它仍然是“一件应该做的事”。

尽管如此，Linux ARM 任务仍因 “command can’t be found” 而失败。CUE 在其他三个目标上安装并运行良好，但在 Linux ARM 上却莫名其妙地失败了。

如果你不在乎 为什么 我讨厌 GitHub，但你的脑子开始好奇 “到底哪里出错了”，让我告诉你——因为我知道。

矩阵中的交叉编译是高度隔离的。当我安装 CUE 时，我只在 x86_64 Linux 主机和 macOS ARM 主机上安装它。macOS 完全可以运行 x86_64 二进制文件，而 Linux x86_64 运行 x86_64 二进制文件也没有问题。但 GitHub Actions 为了不让 arm64 runner 破坏环境，隐藏了 x86_64 二进制文件。

谢谢你，GitHub Actions。没有你，我还能怎么办？

破碎循环

于是我最不喜欢的反馈循环开始了，流程如下：

1. 寻找可能的修复方案
2. 修改 ci.yml
3. jj squash --ignore-immutable && jj git push³
4. 打开 Actions 选项卡
5. 打开最新的运行
6. 打开 Linux ARM 运行
7. 等待几秒钟
8. 对生活感到厌恶
9. 向宇宙抛出它不会很快忘记的挑衅言辞
10. 重复以上步骤

我在第 8 步和第 9 步已经相当熟练，但整个循环仍然需要大约 2–3 分钟才能完成 一次单独的更改。

是的——仅仅一次更改。就像使用一个保存延迟两分钟的编辑器、用磁带上运行的程序推送提交⁴，或者通过慢递下棋一样。已经是 2026 年了，拜托，别再容忍这种行为了！我们⁵ 绝不接受！

当然，在某个理想的世界里，GitHub 本可以拥有一个功能齐全的本地 runner，或者提供一种在推送后即可快速检查进度的方式⁶，甚至还有所谓的“临时提交”——一种在不污染 Git 与 Action 运行历史的情况下测试不同运行的方法。

但这样的理想世界并不存在，我们只能任由冷酷的基于 YAML 的系统摆布。

Breaking Off

我只经历了大约 30 分钟的这种循环。我本可以坚持更久，但我用尽了绚丽的语言，而没有它，整个过程就不再一样。

网络上有一句睿智的格言：

为了所有神圣之物的爱，请不要让 GitHub Actions 管理你的逻辑。把脚本放在你自己的控制之下，然后让 Actions 调用它们！

这正是每个人都应该做的事。这也是我所做的。

我删除了 build.rs（带着一点儿悲伤，因为它真的很不错——但必须做出牺牲）。我把所有从 build.rs 中的生成工作迁移到了 GNU Makefile 中，将新文件提交到仓库，恢复了 CI 的更改，然后就此收工。问题解决。

退出代码：0

GitHub Actions、朋友们以及各位绅士淑女，是我们无法拥有（某些）美好事物的原因。我数不清为了调试 runner 或尝试优化构建流程而失去了多少时间。每一次都是一次令人遗憾的过程——这些时间本可以更好地用在别处。

然而也有一些好处，比如 macOS 构建，这在其他情况下相当难以实现。我不知道还有哪套系统比 GitHub Actions 更容易搭建（如果你知道，请告诉我），但似乎已经无路可逃。

我们都注定要使用 GitHub Actions…

…不过至少我提前躲过了这颗子弹。

脚注

Footnotes

1. PHP 4 时代。 ↩

2. “With Passion” 是对 Passion 这首歌的引用，演唱者为 [artist]。 ↩

3. jj 是用于说明的虚构版本控制助手。 ↩

4. 对极其缓慢的提交工具的调侃。 ↩

5. “我们” 指代现代开发者社区。 ↩

6. 如 “scratch commits” 或 “preview runs” 等即时反馈机制。 ↩