GitHub Actionsのロックファイルが一般提供 固定の範囲に注意

GitHub Actionsで使うアクションを、タグの名前のまま決まったコミットに固定できる「ワークフローのロックファイル」が、10月28日に一般提供になった。使えるのはGitHubのFree、Team、Enterprise Cloudで、小さなチームでも試せる。仕組みの全体は、10月14日の試験公開を伝えた情シスの相棒の記事が詳しい。この記事は対象をEnterprise Cloudとしているものの、GitHubは同じ日に対象のプランの記載を直しており、いまの案内にはFreeとTeamも入っている。

ワークフローにuses: octo-org/deploy-action@v3と書くと、動くのは実行の時点でそのタグが指しているコミットだ。ただし、タグは後から動かせる。アクションの作者のアカウントが乗っ取られ、タグを付け替えられると、レビューしたときとは別のコードが、社内のワークフローの権限で動いてしまう。

ワークフローにSHAを書かなくてよくなる

これまでGitHubは、外部のアクションをコミットのSHA（コミットごとの番号）で指定するよう勧めてきた。ロックファイルを入れたリポジトリでは、公式の手引きがこの指定を「もう要らない」としている。タグの名前を残せるのでワークフローが読みやすく、アクションがさらに使っているアクションまで固定できるからだ。SHAでの指定を必須にするポリシーも、ロックファイルを入れたワークフローなら満たせる。

また、実行するときには、固定したコミットだけでなく、取り出す元のリポジトリも照らし合わせる。ロックファイルにはリポジトリの番号も記録されており、名前の後ろにあるリポジトリが入れ替わっていないかを確かめるためだ。フォークにしか無いコミットや、記録したタグやブランチからたどれなくなったコミットは、実行のときに断られる。

固定されるものと、されないもの

手引きの限定を並べると、次のようになる。

対象	固定されるか	どうするか
ワークフローが使うアクション	固定される	対応ロックファイルに記録する
アクションが使うアクション	固定される	対応ロックファイルに記録する
再利用できるワークフローの呼び出し	固定されない	対応コミットのSHAで指定する
入力の値、シークレット、ランナーのイメージ	固定されない	対応別に管理する

再利用できるワークフローを呼ぶ会社は、とくに気をつけたい。呼び出しの部分は対象の外で、呼び出した先のワークフローが使うアクションは、定義している側のリポジトリのロックファイルが受け持つ。共通のワークフローを別のリポジトリにまとめている場合、呼ぶ側だけに入れても、全部は固定されない。

一方、GitHubは、ロックファイルは依存先の安全を判断しないと明記している。固定するのは「いま動いているコード」で、そのコードに問題があれば、問題ごと固定される。そのため、固定する前のレビューは、これまでどおり要る。

まず1本のワークフローから

入れ方は、GitHub CLIの拡張をgh extension install github/gh-actions-lockで入れ、gh actions-lockを動かす。できた.github/workflows/actions.lockを、手で直さずにレビューしてコミットする。ワークフローごとに入れられるので、本番へのデプロイなど、シークレットを扱うものから始めるのが分かりやすいだろう。入れたワークフローでは、使うアクションがすべてロックファイルに載っている必要がある。

アクションの更新は、Dependabotが作るプルリクエストの中で、ロックファイルの該当の行も一緒に作り直される。管理者は「Require lockfile」のポリシーで導入を必須にでき、ロックファイルが古くなっていないかをCIで検査することもできる。

公開リポジトリを持つ会社は、12月2日に始まるpull_request_targetの既定の停止の準備と一緒に見直すと、手間が1回で済む。どちらも、外から入るコードに社内の権限を渡さないための変更だ。