- GitHub Actionsに対する不満
- チームは約15人のエンジニアで構成されており、全員が
main ブランチに継続的にコードをプッシュしている
- コードは複数のモジュールに分かれたモノレポ構成で存在し、トランクベース開発方式によって1日に何度もデプロイされる
- GitHub Actionsをうまく使えるケースもあるが、特定の規模や環境では限界が明確に表れる
Pull requestと必須チェック項目
- モノレポは複数のフォルダに分かれており、各フォルダごとに独立してテスト、ビルド、デプロイを行う
- GitHub Actionsの
paths 機能を使って、特定のフォルダに変更があったときだけ該当パイプラインをトリガーする
- Pull requestのマージ前にすべてのチェックが通過していなければならないというのは良い原則だが、モノレポ構造と組み合わさると問題が発生する
- 例:
web-app1 - Unit tests というチェックを「必須」に設定していても、web-app1 フォルダに変更がなければそのチェックは実行されない
- その結果、片方のフォルダだけが変更された場合でも、別のフォルダに関するテストが実行されず、マージ自体が不可能になる問題が発生する
- GitHub側で、必須チェックの名前ベースではなく、「今回トリガーされたチェックがすべて通過すればマージ可能」のような方式で処理してくれれば解決できそうだが、3年間変わっていないのが残念な状況だ
- 関連するGitHubのイシュースレッド 1, 2 でも、この問題の影響の大きさが確認できる
- 結局これを回避するために追加のパイプラインを実行したり保守したりする必要があり、複雑でコストも高くつく状況になっている
再利用性とYAML
- パイプラインの規模が大きくなるほど、GitHub Actionsで管理するのがますます難しく感じられる
if 文が多くなり、ワークフローを分割しても管理すべきファイルが増えるため、保守性が下がる
- 再利用時には1行で済むべき呼び出し部分にも複数行と重複設定が必要で、
.github フォルダにはすでに30個以上のファイルがたまっている
needs 節も、リファクタリング時に削除されたジョブへの反映漏れがあると、エラーに気づくまで時間がかかる- GitHub Actionsはローカルで実行できないため、開発とテストが難しい
act のようなツールはあるが、実際に使うと制約が多く、期待に届かないことが多い
GitHubの無関心
- 上記の問題点の中で最大の問題は、GitHubがこれらのイシューをあまり重要視していないように見える点だ
- 多くのイシューが何年も開いたままで、公開ロードマップにも含まれていないことから、改善の意思が見えない
- 長らく話題になっていた問題も、最近イシューが大量にクローズされたことでコミュニティの反発を招いた
オプション
- こうした問題とGitHubの改善意欲の乏しさを考えると、GitHub Actionsを導入する前に慎重になる必要がある
- 市場にはGitLab、Jenkins、TeamCityなど、ほかにもさまざまなCI/CDの選択肢がある
- Daggerのように新しいアプローチを提示するツールも検討する価値がある
6件のコメント
CI/CDはgitlabが最高
自分もGitLabを使っていて、GitHub Actionsの環境に置かれたときは、うまくいくものが何もないなと思った記憶が…
GitHubでリポジトリをグループごとにまとめて管理できないのも、私にとって大きな不満の一つです..
パイプラインはGitLabが本当に優れていると思います。上で言われていたことは、GitLabならすべてできます。
モノレポの場合、どのフォルダが変更されたら何を実行すべきかを設定しやすいです。
これはGitHub Actionsの歴史を知っていないといけない話ではあるのですが...
最初期のGitHub Actionsは、今の状況とは違う様相を見せていましたよね...
公開の6か月前に（記憶があいまいですが）GitHubがMSに買収され、Actionsの開発はMSでAzure DevOpsチームと一緒に進めることになったのだと思います。
このときAzure DevOpsにはもう新機能が出なくなり、Azure DevOpsにあった機能がGitHub Actionsで新機能として出ていたような...
その頃にYamlへ変更されて、今の環境が作られたんですよね.... T_T
その後、開発者たちが元の担当に戻って、もうあまり手が入れられていない状態に見えるので...
残念ですね...
今の会社ではGitHub ActionsベースでCI/CDを構成していて... まだ不足している点がないので使っていますが...
注視していないといけませんね...
Hacker Newsの意見
パイプラインDSLには実際のロジックを含めず、作業のオーケストレーションにだけ使うべき。複雑な処理はスクリプトとして作成し、簡単に実行できるようにすべきである。こうすることで、GitHub Actions、Jenkins、Azure DevOps などで同じ作業を簡単に実行できる
GitHub Actions を設定する際は、既製の Action を避け、単純なシェルランナーとして使うのがよい。Python、Ruby、Bash などでスクリプトを書き、GitHub Action からそれを実行すれば、ローカルでのテストがしやすくなり、不要な苦痛を減らせる
GitHub Actions は特定の条件が満たされたときだけチェックを実行できる。しかしこのようなルールを使うと、「Pull request と必須チェック」の問題に直面する。外部サービスと組み合わせて使う場合、必須チェックは必ず通過していなければならず、そうでないとマージできない
「Pull request と必須チェック」の問題を解決する方法として、各必須チェック用ワークフローの
no opバージョンを作成し、条件が満たされないときにそれを実行して終了コード 0 で終わらせることができる。この方法は基本機能の範囲内だが、やや複雑な回避策であるTravis CI はローカルで CI をテストするのに素晴らしかった。GitHub Actions は GitLab CI と競争するために作られ、企業市場でシェアを失っていた
Buildkite を試してみることを勧める。GitHub Actions の次に進むなら、Buildkite はよい代替になりうる。米国の大規模テック企業で使った経験があり、CI の中で唯一楽しい部分だった
GitHub Actions のアーキテクチャは、セキュリティ上の判断を誤らせる可能性がある。たとえば、組織またはリポジトリのシークレットは便利だが、セキュリティ脆弱性になりうる。リポジトリ環境は別個のシークレットを持てるが、正しいワークフローだけが正しい環境にアクセスできるようにしなければならない
CI システムの一般的な哲学は間違っている。CI がコードを実行するのではなく、コードが CI を実行すべきである。CI は API を提供し、ユーザーがシステムに情報を渡せるようにすべきだ
Bazel を使って CI ツールに Bazel ターゲットをビルドさせ、必要に応じてリモートビルド実行によって並列性を高められる。これは約 10M+ 行のコード、または大規模サービスに適している
GitHub では「必須チェック」を指定でき、これは常にグリーンでなければならない。しかし特定のフォルダに変更があるときだけ実行されるため、別のフォルダに変更がある場合はマージできない。すべてのテストを実行しないなら統合の意味がなくなるので、テストを高速に実行できるようにすべきだ