私はGitHub Actionsを情熱的に嫌っています。

Japanese Translation:

著者はGitHub Actionsを強く嫌悪しており、PHPなどの古いツールと比較しても劣っていると述べています。tmplrプロジェクトでは、

build.rs

スクリプトとCUEを使用してドキュメントファイル（

README.md

、

CHANGELOG.md

など）を生成しました。しかし、Linux ARMランナーでCIビルドが失敗したのは、GitHub Actionsによってx86‑64専用のCUEバイナリが隠されていたためです。これはLinux x86_64とmacOS（ARMおよびx86_64）では正常に動作していました。

各再試行は

ci.yml

を編集し、コミットをプッシュし、Actionsタブを確認し、次の実行まで2〜3分待つという非常に非効率的なループでした。著者はローカルランナーや「scratch‑commit」機能がないことに苛立ち、約30分間の繰り返しサイクルの後で

build.rs

アプローチを完全に放棄しました。

生成ロジックはGNU Makefileへ移動され、生成されたファイルはコミットされ、CIの変更は元に戻されました。著者はmacOSビルドのためだけにGitHub Actionsを使用し続けつつ、そのARM制限を回避することにしました。結論として、GitHub Actionsは貴重なmacOSサポートを提供しますが、同時に大きな時間損失とデバッグ作業を引き起こすため、彼らのニーズには他のシステムよりも簡単であることが証明されていません。

2026‑01‑14

GitHub Actions を嫌うほどに言い過ぎることはありません。
他のテクノロジーを使っているときに「嫌だ」とまで言えるものは思い出せません。
PHP 41 の時代から PHP を冗談で笑ったことはありますが、当時もそれほど好きではありませんでした。
ただ、その時点で Ruby on Rails や Django などの新興技術に比べて「劣っている」と感じただけです。
しかし GitHub Actions はその感覚を超えて嫌いになりました。

地獄への道
この言葉を書いた前日、私は tmplr プロジェクト用の

build.rs

を実装していました。
簡単にお伝えすると、これは人間が読みやすく（そして作りやすく）テンプレートファイルを扱うプロジェクトスキャフォールドツールです。私自身も頻繁に使っており、新しいテンプレートを手で書いたりツールの助けを借りて作成することがとても簡単です。

build.rs

では CUE を利用して

README.md

、

CHANGELOG.md

、さらにバージョン/ヘルプファイルを生成し、一貫性を保証しています。
楽しいプロジェクトで、約1.5時間ほどかけて実装しました。
結果に満足し、CI の出力は確認せずにいましたが、それは当然失敗していたでしょう。

build.rs

内で CUE バイナリを呼び出しており、バイナリが無いとビルドは進まないためです。翌朝起きて CI からのメールで「ビルド失敗」と通知されると、一日が子犬や虹で始まるわけではなくなることを直ちに悟りました。

CUE をインストールする GitHub Actions を探してプッシュし、
最悪の結果：マトリクス内の一つのシステムだけビルドに失敗しました。

説明すると、tmplr は以下の四つのプラットフォーム向けにビルドしています。

Linux ARM
macOS ARM
Linux x86_64
macOS x86_64

意味は通じますよね？
ユーザー数が「片腕を持つ指一本」と言えるほど少なく、もう一方の腕はフック付きパイレーツであるといっても、「やるべきこと」です。
Linux ARM だけが「コマンドが見つからない」というエラーで失敗しました。CUE は他の三つのターゲットでは問題なくインストール・実行されました。

なぜ GitHub Actions を嫌うか気にしない方もいらっしゃるでしょうが、
何が悪かったのか疑問に思ったら説明します ― 私自身が知っているからです。

マトリクスで起きるクロスビルドは非常に隔離されています。
CUE をインストールする際、x86_64 Linux ホストと macOS ARM ホストだけにインストールしています。
macOS では x86_64 バイナリを実行しても問題がなく、Linux x86_64 でも同様です。しかし GitHub Actions は arm64 ランナーから x86_64 バイナリを隠すため、失敗しないように配慮しています。

ありがとうございます、GitHub Actions。
あなたがいなければ私は何をしたでしょう？

壊れたループ
そして私の最も嫌いなフィードバックループが始まりました。

可能な修正を検索
```
ci.yml
```
を変更

jj squash --ignore-immutable && jj git push 3

「Actions」タブを開く
最新の実行結果を表示
Linux ARM の実行を選択
数秒待つ
Hate Life
宇宙に語りかける言葉がすぐに忘れられないように
Rinse & repeat

ステップ 8 と 9 はかなり効率的でしたが、残念ながら全体のループは変更一つで約2〜3分ほどかかりました。
単なる変更です。
エディタが２分間保存遅延を持ち、コミットがカセットテープで実行されるプログラムを使い、チェスがウサギ郵便で送られるような感覚です。2026年なのに、この挙動は許容できません！

理想的には GitHub はすべての機能を備えたローカルランナーを持っているか、プッシュ時に進捗を素早く確認できる仕組みや「スクラッチコミット」（Git と Actions の履歴を汚さずに異なる実行をテストできる方法）を提供してくれたらと思います。しかしそのような完璧な世界は存在しません。私たちは心のない YAML ベースのシステムの支配下にあります。

中断
私はこのループに 30 分だけ費やしました。もっと長く続けることもできましたが、言葉を使い果たしたので、プロセスは同じであっても違うと感じました。

インターネットには「神聖なるものすべての愛のために、GitHub Actions にロジックを管理させないでください。自分のスクリプトを完全にコントロールし、Actions が呼び出すだけにしてください！」という賢明な格言があります。これは誰もが行うべきことです。私もそうしました。

build.rs

を削除しました（それは本当に素晴らしかったので少し寂しいですが、犠牲を払わざるを得ませんでした）。
すべての生成処理を GNU Makefile に移動し、ファイルをリポジトリにコミット。CI の変更を元に戻し、一日を終えました。問題は解決です。

Exit Code: 0
GitHub Actions は友人でありやさしい存在ですが、私たちが（ある種の）素敵なものを手に入れられない理由でもあります。デバッグランナーやビルドプロセス最適化に費やした時間は数え切れません。毎回遺憾なプロセスであり、もっと他所で使えるべきだった時間です。

それにもかかわらず、macOS ビルドのようにほぼ不可能に近い環境を取得できるメリットもあります。他に GitHub Actions より簡単にセットアップできるシステムは知りません（もし知っている方がいたら教えてください）。結局私たちは GitHub Actions に追われている… ですが、少なくとも私は早めに回避しました。

私はGitHub Actionsを情熱的に嫌っています。

Japanese Translation:

同じ日のほかのニュース