GitHub Actionsがエンジニアリングチームを徐々に疲弊させている

作者が挙げているCIシステムは色々使ったけど、CircleCIやGitHub Actionsもたくさんやってきたけど、あんまり同じ結論には至ってないな。ただ一つ注意点があって、作者が推してるBuildkiteは使ったことがないんだよね。年々、CIツールは専門的なものから一般的なものに変わってきた。JenkinsはもともとJavaプロジェクトのビルドには優れてたけど、それ以外はあんまりだったし、TravisもRailsプロジェクト用の明確なステップがあった。CircleCIも昔はそんな感じだった。これは行き止まりだったんだ。CIは特別なものじゃないって、コミュニティとして気づいたんだよね。実際、CIジョブは多様で、ウェブフレームワークや言語の知識をCIシステムに組み込むのは良くないアイデアだって分かったから、CIシステムは一般的なワークフローオーケストレーターになったんだ。ログや合否のUIがちょっと乗っかってるだけ。これは良いことだよ！CircleCI 2からGitHub Actionsに移行したのも、まさにCircleCIが専門から一般モデルへの移行を失敗したからで、そのモデルではパフォーマンスが良くて正しいCIシステムを表現できなかったんだ。GHAではそれができた。GHAにも欠点はあるけど、ログブラウザ？どうでもいいよ、ファイルをダウンロードすればいいし、少なくともCIは動くから。YAML？まぁ、ちょっとYAMLじゃないけど、設定フォーマットに追加の意味を持たせるのは最初でも最後でもないし、全てのCIシステムには独自のクセがあるからね。プラグインがDockerイメージ？重いかもしれないけど、正直言って悪いUXではないよ。何が大事かって？自分のコンピュートを持つこと？そうだね！これは重要だけど、主要なCIシステムではどれでもできるから、差別化にはならない。ダイナミックパイプライン？それは本当に素晴らしいし、Buildkiteを選ぶ理由としてはいいね。これらのプラットフォームでの経験からの私の結論は、Actionsは本当に重要な点では「かなり良い」し、他の点では問題ないってこと。もし会社を始めるならBuildkiteを選ぶかもしれないけど、オープンソースプロジェクトにはActionsがいいよ。

最近のGitHubはどんどん信頼性が低くなってるから、これがますます真実になってる。先週見たことは： - actions/checkoutが理由もなく失敗して、3回目のリトライでやっと成功することもあった - リリースCIジョブが2回スケジュールされて失敗することがあった、だってもちろんリリースはすでに存在してるし - ジョブがスケジュールされないこともあった。時には40分も。数年間アクティブに使ってきたけど、作者が言ってることを置いといても、基本的な信頼性がどんどん悪くなってる。zigが正しかったんだろうね。Buildkiteを逃したのは残念だけど、Codebergは私の経験ではあんまり信頼性も速さもなかった。

これにはあまり賛同できないな。Nix/Buildkiteの宣伝みたいに見えるし… CIの呼び出しがスクリプトやビルドツール（makeとか）のターゲットを実行する以上のものであれば、CIシステムを必要以上に複雑にしてることになるよ。CIジョブはせいぜい、開発者がローカルでやるように環境や設定（認証情報、エンドポイントなど）を提供するだけでいいと思う。これによって、コードがCIに依存しなくなるから、システム間の移行もかなり簡単になるし、最小限のロジックで済むから、単なるコマンドの呼び出しになるんだ。

その通り。GitHub Actionsは今まで使った中で最悪のCIツールだよ（Jenkinsと同じくらいかも）で、Buildkiteが最高。Buildkiteのダイナミックパイプライン（投稿の最後の項目）は本当に役立つから、これなしでどうやってやってたのか不思議になるよ。ユニットテストのステップがテストに失敗したときだけ、テストのデフレークステップを生成するような超クールなことができるんだ。あるいは、テストしているコードの変更に基づいてテストの並列性を制御することもできる。これらすべてが、自分のランナープールを持つための堅牢なシステムの上で実現できるから、各CIジョブのために全く異なるマシンタイプや構成を使える。超おすすめだよ。