GitHub Actions と CircleCI を「ローカル環境実行」という観点で比較

注意

2021/09/26 時点での情報です。

前提

• GitHub Actions では act を用います
  • gh コマンド は push されたものを手元から発動するコマンドであって、ローカル環境に存在するジョブを実行するものではないです
• CircleCI では 公式の CLI ツール を用います

結論

• ちょっと込み入った使い方をする場合には act はつらいという印象です
  • CircleCI には YAML のバリデータがある*1ので、それについては CircleCI が便利
  • act は厳密なチェックをしてくれるという意味では有用でもあるし不便でもある
    • 例えば、特定の on: でしか使用しない {{ github.foo.bar }} を共通のジョブに組み込んでいるとき、それが定義されてないというエラーが出る
  • 一方で act では一部の記述が誤判定？される
    • 例えば、run: | 内で # で実行行をコメントアウトするとエラー*2になる（シェルスクリプトのコメントアウトなのでエラー出してほしくない）
• いずれにしろ archive.ubuntu.com 遠い（遅い）問題 がついてまわります
• GitHub Actions については将来的に gh コマンド に組み込まれそうな予感はします

補足

ローカルで実行する意義というのは以下になるかなと思います。

1. CI の無料利用時間を消費したくない
2. CI の実行テストのためのコミットを積みたくない・見せたくない*3

「1.」についてはプライベートリポジトリのみの話なので*4、プライベートリポジトリにした上で無料時間の消費を気にするならば素直に💴で叩くべきだとは思います*5。

あるいは「セルフホストランナー」をサクッと立てるのもよいと思います（これ自体は無料です）。GitHub 側としてはローカル実行するならばこの選択肢を選んでもらいたいのではないかと想像しています*6。

「2.」については……まあそういうときはあるのですが、たとえばセンシティブな情報を直書きとかしないのならば、後からsquashする前提でコミットメッセージに「CI のテスト中」であることをそれっぽく書いていれば見る人も察してくれるんじゃないかなと思います。

ローカルの実行では遅すぎたりマシンリソースを持っていかれないようにしたりするために SaaS を使っているので、そのメリットを享受しない理由としては弱いんじゃないかなと思っています*7。

そしてローカルだととにかく apt が遅いのがつらい*8。

参考

zenn.dev

*1:$ circleci config validate

*2:Unable to interpolate string

*3:あとで squash することは前提です

*4:パブリックリポジトリの場合、GitHub Actions は実行上限なし、CircleCI の場合は使い切れないぐらいの無料時間が追加される

*5:特に業務利用の場合

*6:リポジトリごとに設定するのが面倒ですが……

*7:トライアンドエラーを回すスピードというのは開発速度や開発体験、モチベーションに直結すると思います

*8:npm や rubygems も遅い