GitHub Actionsでは任意のプログラムをシェルとして使用可能

• GitHub Actionsでrun:ブロックを実行するときに使うシェルは、shellキーワードで指定できる
• ワークフローでは任意だが、個別のアクション定義では必須項目
• デフォルト値はOSに応じて自動設定される: Linux/macOSはbash、Windowsはpwsh
• 明示的にshell: bashを設定すると、次のようなデフォルトフラグも含まれる: --noprofile --norc -eo pipefail

任意の実行ファイルをshellとして指定可能

• 一般には、shellに使える値は限定されていると思いがち
• 実際には、$PATH上にあるあらゆる実行ファイルをシェルとして使える
• 実行コマンドがファイル入力を受け取らない場合は、特別な引数{0}を渡す必要がある
• {0}はGitHubが自動的に一時ファイルのパスへ置き換える

実験的な例

• C言語コンパイラ（tcc）をシェルのように使って直接実行することも可能
• $PATHを操作して偽のbashシェルを作って使うことも可能
• GitHubはshell項目に指定された値が実際にどんな実行ファイルであっても気にしない

セキュリティ上の示唆

• GitHub Actionsでは、ファイル書き込みと実行の境界が曖昧（GITHUB_ENV、$GITHUB_PATHなど経由でも実行可能性がある）
• shell: bashのようなよく知られた値でさえ$PATH経由で探索され、固定の実行パス（/bin/bash）は使われない
• 予想に反して、pythonのような値も単なるツールキャッシュ参照ではなく、実際のパスベース実行になっている

[tujuc]

github/runner-image レポジトリを見るだけでも、そのまま使えるパッケージがかなり多くインストールされていますよね…。

イメージを作ると、1GBくらいはあっという間に入ってしまう…。

[GN⁺]

Hacker Newsのコメント

• 以前、bash の -x フラグを使って、Actions ワークフローで実行されるすべてのコマンドを出力するよう強制したことがある。デバッグに非常に便利だった
• 作業中に見つけた GitHub Actions のすてきな非公式トリックは、ワイルドカードを使って repository_dispatch イベント名をマッチさせること
  • これは、集中管理されたリリースパイプラインを通じて定義された再利用可能なワークフローを強制できる唯一の方法だ
  • イベントをディスパッチするときに、製品とバージョンを簡単に識別できる
• GitHub Actions でやることは少ないほどよい、という経験則がある
  • ビルドシステム（例: Make）を使ってロジックをエンコードし、GitHub Actions から呼び出すか
  • 小さな CLI プログラムを書いて GitHub Actions から呼び出すのを好む
  • ローカルでデバッグするほうが、CI 上でデバッグするよりはるかに簡単だ
• スプレッドシートをコードに変換しろと言われて恐れていた世代があった
  • その世代は、GitHub Actions で構築されたデプロイに規律を与えろと言われたときに恐れるだろう
• GitHub Actions Runner のコードは読みやすい
  • 一般的なシェル/バイナリ向けのデフォルト引数を定義している特定の場所がある
  • ScriptHandler.cs には、プロセス環境や引数などを準備するコードがすべて入っている
  • 全体として、このコードの単純さには良い意味で驚いた
• デフォルトシェルの bash をだまして、どんなプログラムでも実行できる
  • 他のアクションの読者が何が起きているか分かっている限り、これはとても有用だ
  • シェルスクリプトが数行で始まり、100 行を超える怪物に成長した経験がある
  • Python 標準ライブラリの配列や型を含む機能が欲しかった
• GitHub ワークフロー YAML ファイルから、CI ジョブを直接実行する Go コードを簡単に走らせられるかもしれないという希望を与えてくれる
  • goeval はまだファイル入力を直接サポートしていない
  • シェルトリックが必要だ
  • 多少のボイラープレートが必要だ
  • 自分は goeval の作者だ
• GitHub CI yaml の利点が何なのか気になる
• CI/CD で C を書いて、それを低レベルなシステム作業と呼べるようになった
  • アセンブリも書けるだろう