GitHub Actionsがもたらす苦しみ

 (feldera.com)
2 ポイント 投稿者 GN⁺ 2025-03-21 | 1件のコメント | WhatsAppで共有

  • GitHub Actionsの問題点

    • 最近、CIスクリプトをGitHub Actionsで書き直すのに多くの時間を費やした。以前はEarthlyを使っていたが終了したため、再びGitHub Actionsに戻った。
    • CIは複雑で、マージキュー、複数のランナー、Rustビルド、Dockerイメージ、統合テストなどを含む。すべてのPRマージのたびに多くのCI時間が消費される。
    • 良いソフトウェア開発の実践として、すべてのテストに通過しなければならず、些細なミスは自動で修正されるべきであり、テストしたアーティファクトはリリースと同一であるべきだ。GitHub Actionsはこれを可能にするが、設定は複雑で一貫性に欠ける。

  • ステータスチェックとマージキュー

    • GitHubのマージキューは、PRをメインブランチにリベースした後にCIを実行する。しかし、CIはキューに入れる前と後の両方で実行する必要があり、その設定は難しい。
    • 解決策は、2つの段階でジョブ名を同じに設定することだ。これにより、両方の段階を通過する必要が生じる。

  • セキュリティの問題

    • 最近、人気のあるGitHub Actionが侵害された。対策として、依存関係をハッシュで固定するよう勧告されたが、ほとんどの利用者はそれをしていない。
    • GitHubのセキュリティモデルは複雑で理解しにくい。GITHUB_TOKEN のデフォルト権限は設定できるが、権限を取り除く方法は明確ではない。
    • ワークフローの権限はAction自体には依存せず、コード内で権限を引き上げるのは不自然だ。

  • DockerとGitHub Actionsの組み合わせ

    • GitHub Actionsではコンテナ内でジョブを実行できるが、ファイル権限の問題や $HOME ディレクトリの場所変更などにより問題が発生する。
    • container フィールドには制限が多く、エントリーポイントを上書きしたり、一部のステップだけをコンテナ内で実行したりすることはできない。

  • YAMLでのワークフロー開発

    • YAMLでロジックを書くのは複雑になりがちで、ミスをしやすい。RustRover IDEを使って一部のチェックは行ったが、より優れた静的チェックが必要だ。
    • ローカルでテストしにくいため、同じリポジトリを作って、CIが動くまでコミットとプッシュを繰り返さなければならない。
    • ワークフローは小さく保ち、アーティファクトをpushして他のワークフローで再利用できるようにしている。しかし、アーティファクトをダウンロードするにはトークンが必要になる。

  • 結論

    • 新しいCIスクリプトによってマージ時間は大幅に短縮されたが、設定プロセスは複雑で、デバッグも難しい。イノベーションが必要だ。

関連記事

1件のコメント

 
GN⁺ 2025-03-21
Hacker Newsの意見

  • GitLabのほうが良いという意見もあるが、GitLabにも別の形の問題がある

    • 複数のCIツールを使ってみた結果、できるだけ多くのCIロジックを自前のコードで書くことが重要
    • 開発者マシンでパイプラインをローカル実行できるように投資すべき
    • YAMLの使用は可能な限り避けるべき
    • VC資金を受けた新しいツールに依存すべきではない
    • 可能な限りセルフホストランナーを使い、オンプレミスで運用すべき

  • GitHub ActionsとDevOpsが広く批判されているのは興味深い

    • 設定とテストは面倒なこともあるが、一度動けばほとんど触らない
    • Nodeのバージョン更新以外では、4年間ほとんどワークフローを修正していない
    • 個人的には満足している

  • GitLabを使っていてGitHubに移行したが、がっかりした

    • GitHub ActionsはGitLabに比べてかなり物足りないと感じる
    • 会社を運営するならGitLabを選ぶだろう

  • フィードバックループが30〜60秒なのは最悪

    • GHA環境をローカルで再現しようとしたが無理だった
    • 小さなミスのせいで多くの時間がかかる

  • CIが自動でコードを修正するのは望まない

    • 軽微なチェックはpre-commit hookで実行されるべき

  • GitHub Actionsの進化が止まったように見えて残念

    • EarthlyとDaggerの開発停止が惜しまれる
    • Depot.devを評価したところ、とても賢いチームが問題をうまく解決していた

  • GitHub Actionsがコンテナをインストールスクリプトとして誤用させてしまう

    • ワークフローでは多くの時間がインストーラーの実行に費やされる

  • 適切なツールを選ぶことが重要

    • GitHub Actionsは単純な作業には向いているが、複雑な作業には向いていない

  • GitHub Actionのセキュリティ問題のため、ハッシュを使って依存関係を固定すべき

    • ハッシュを使えばはるかに安全

  • GitHub Actionsには多くの問題点がある

    • 10GBのキャッシュ制限、ランナー種別ごとの同時実行制限、高コストなど
    • Depot.devはGitHub Actionsをより高速にし、問題を解決しようとしている
    • Dockerイメージのビルドを高速化し、ランナーを最適化して作業を非常に速くする
    • GitHub Actionsは人気が高いが、改善の余地が大きい