2 ポイント 投稿者 GN⁺ 2023-09-24 | 1件のコメント | WhatsAppで共有
  • 著者は2019年からGitHub Actionsの日常的なユーザーであり、再利用可能なワークフロー、OpenID Connect、ジョブサマリー、GitHub Mobileとの統合といった新機能を高く評価している。
  • しかし著者は、GitHub Actionsでのデバッグ作業が時間を要し、複数のコンテキスト切り替えを伴う点に不満を示している。
  • 著者は、対話型デバッグシェルや、明らかに無効なワークフローを含むコミットを拒否するリポジトリ設定などの改善を提案している。
  • 著者はまた、潜在的に脆弱なワークフローを簡単に書けてしまうことや、フォークと非フォークのSHA参照の区別がないことなど、GitHub Actionsのセキュリティ上の問題も強調している。
  • 著者は、安全でないワークフローのpush時拒否、ワークフローに対するランタイム検査、より制限的なデフォルトのトークンスコープといった解決策を提案している。
  • 著者はさらに、GitHub Actionsに型強制が存在しないことを批判しており、その結果として保守性やセキュリティの問題が生じるとしている。
  • 著者は、アクションおよびワークフローの作成者がどこでもtype:を使えるようにし、より厳格な型チェックを実施し、type: objecttype: array型を導入することを提案している。
  • 著者はまた、GitHubにより多くの公式アクションを求めるとともに、最大手のサードパーティー製アクションと協力して、より多くの準公式アクションを提供することも求めている。
  • 著者は、GitHubのエンジニアたちがこれらの問題意識を共有し、解決してくれることを願っている。

1件のコメント

 
GN⁺ 2023-09-24
Hacker Newsの意見
  • 記事では、GitHub Actionsのワークフローの2つのタイプ、つまりGitHub Actionsでプログラミングすることと設定することについて論じています。前者は複雑で理解しにくいワークフローにつながる可能性があり、後者はよりシンプルで管理しやすいワークフローを生みます。
  • ユーザーは、Microsoftが提供するデバッグツールの不足に不満を示しており、その結果として面倒なコミット・プッシュ・デバッグのループが発生すると指摘しています。デバッグを容易にするため、YAMLの複雑さをスクリプト側に押し出すことを提案しています。
  • 一部のユーザーは、デバッグの問題を解決し、ローカルマシンを含むどこでも実行できるポータブルなパイプラインを作るために、ActやGardenのようなツールを使うことを勧めています。
  • ユーザーは、GitHub Actionsの並列化の不足、コンテナベースのジョブの扱いの悪さ、キャッシュサイズの制限などを批判し、同じVM上でステップを並列実行できないことに不満を述べています。
  • ユーザーは、GitHub Actionsのセキュリティ問題を指摘し、forkと非forkのSHA参照を区別できないために、forkがセキュリティ設定を回避できてしまう可能性があると述べています。
  • 一部のユーザーは、コミット前にコードのチェックと修正を行うために pre-commit.ci を使うことを勧めており、これが高速に動作し、多くのデバッグ問題を解決すると述べています。
  • ユーザーは、現在の actions/upload-artifact を使わずに、アクションの実行結果にHTMLレポートを添付できる機能を望んでおり、ジョブサマリーにHTMLレポートへのリンクを置く "attach-report" アクションを提案しています。
  • ユーザーは、自分のローカルマシンですべてのCIワークフローを実行できるようにする Earthly のようなプロジェクトを支持しており、CIが行う作業の大半はスクリプトや他の非CIツールで抽象化されるべきだという点に同意しています。