GitHub Actionsの依存ロックが一般提供：タグを読みやすく保ち、実行するコミットを固定する

GitHubは10月28日、Actionsのworkflow dependency lockfilesを一般提供した。Actionsは、テストや公開作業を自動実行する仕組み。今回のロックファイルは、そこで呼び出すアクションの実体を、特定のコミットへ固定するためのものだよ。

「設定にはv4と書いてあるのに、昨日と同じコードが動くとは限らない」という問題に関係する更新。タグの読みやすさを保ちながら、実行コードの変更をレビューしたいチームに向いている。

何が固定される？

一般提供の発表では、Free、Team、Enterprise Cloudとデータレジデンシー対応環境を対象としている。

タグやブランチは参照先が移動することがある。ロックを導入したワークフローでは、表示上のタグだけでなく、記録済みのコミットを使ってアクションを実行する。別のアクションから呼ばれるアクションも対象に含む。

ただし、固定できることと、安全なコードであることは別。導入前の依存先レビューは引き続き必要だよ。

再利用ワークフローと、実行環境は別に確認する

公式の概念説明では、jobsのusesで呼ぶ再利用ワークフローそのものは、この仕組みで固定しないと説明している。その参照には完全なコミットSHAを使う。再利用先内部の依存は、再利用先リポジトリのロックファイルが扱う。

シークレットはパスワード等の非公開設定、ランナーはジョブを実行する環境のこと。依存コードを固定しても、これらの権限や設定まで変わらなくなるわけではないんだ。

まず一つのワークフローから導入する

以下は公式資料に沿った導入時の確認順で、このサイトへ導入した実測結果ではないよ。

1. 対象リポジトリの作業用ブランチを用意し、アクション、再利用ワークフロー、現在のSHA固定を洗い出す。
2. 認証済みのGitHub CLIから、公式拡張gh-actions-lockのインストール・生成手順を確認する。GitHub Enterprise Serverは同拡張の対応対象ではない。
3. 最初は一つのワークフローを対象にし、生成された .github/workflows/actions.lock とワークフロー側の変更をレビューする。ロックファイルを手で組み立てない。
4. プルリクエストで検証し、想定したコミットへ解決されることを確認する。アクションの更新時には、Dependabotが作る変更とロックの更新を一緒に読む。
5. 導入漏れを把握してから、管理者がRequire lockfileの強制を検討する。

編集部としては、いきなり全組織で必須化せず、小さな対象で生成・更新・失敗時の対応を確かめる順を勧める。必要なファイルを用意する前に強制すると、既存のジョブに影響する可能性があるからだよ。

ジョブが拒否されたら確認すること

導入したワークフローが使う依存は、ロックにそろっている必要がある。追加したアクションのエントリーがない場合は、手修正ではなく公式ツールで再生成し、差分を確認しよう。

記録したコミットが、元リポジトリの指定したタグ・ブランチから到達できるかも確認対象。別のforkにしかないコミットや、参照できなくなったコミットを、確認を無効にして通す手順にはしない。

公式拡張には、ファイルを変えず整合性を確かめる機能も用意されている。具体的なオプションは導入時のREADMEとヘルプで確かめ、生成と確認を混同しないようにしたいね。

CI/CDの公開設定を整理するなら、GitHub ActionsのSecretsとVariablesの違いも合わせて確認してみよう。コードの固定と、渡す設定・権限の管理を両方見ることが大切だよ。