Actions lockfileがGAに：緑のチェックが示す証拠は同じではありません
PRのusesのバージョンは同じでも、実行されるコードが変わることがあります。タグの参照先は移動できるからです。GitHubは10月28日にworkflow lockfileを一般提供しました。プレビュー時の固定の仕組みに加え、導入時には各検証の意味も理解しておきたいところです。
読みやすい参照名と、記録されたコミット
.github/workflows/actions.lockはアクションの参照と実行コミットを結びます。gh actions-lockで生成し、Free、Team、GitHub Enterprise Cloudとデータレジデンシー環境に対応します。ワークフローごとに段階導入できます。手でファイルを組み立てず、生成結果とワークフロー変更を一緒にレビューします。
架空のdemo/build@v1が最初はA、その後Bを指す例を考えます。参照名だけなら次の実行で別のコードを選び得ますが、lockfileは記録したコミットを使います。図は説明用で実行結果ではありません。記録したタグやブランチから到達できなくなったコミットは、実行時に拒否される場合もあります。
オフラインの成功は何を確認したのでしょうか
gh actions-lock --verify-localは通信せず、usesに対応する項目があるかというcoverageを確認します。コミット前の素早い検査には向きますが、来歴を確認したことにはなりません。gh actions-lock --verifyはオンラインでprovenanceを確認し、ランナーもジョブ開始時に再確認します。同じ緑でも意味が違います。
並行するPRがアクションを追加してlockfile更新を忘れた場合、ローカル検査で項目漏れを見つけられます。ただし項目が揃っていても、来歴やコードの安全性が証明されるわけではありません。2枚目は公式資料の範囲を整理した図で、この記事ではCLIをインストール・実行していません。
再利用可能ワークフローには別のリポジトリ境界があります
アクションが利用する推移的依存関係も対象です。一方、jobs.<job_id>.usesの再利用可能ワークフロー呼び出し自体は固定されません。完全なコミットSHAで参照します。その内部のアクションは呼び出し元ではなく、ワークフロー定義先のlockfileに従います。
アプリのリポジトリがプラットフォーム側のデプロイを呼ぶ例なら、アプリのactions.lockだけではプラットフォーム内の固定先は分かりません。呼び出しSHAと定義先の依存変更を一緒に読みます。ランナーイメージ、入力、secretも別の要素で、アクションを固定しても環境全体は固定されません。
更新PRでは2つのファイルを一緒に読みます
Dependabotは導入済みワークフローのアクション更新時に、対応するlockfile項目も同じPRで再生成します。読みやすいバージョンと実際のコミットを並べて見られます。--relockは移動した参照を更新してファイルを書き換えるため、読み取り専用検証とは用途が異なります。コードのレビューは引き続き必要です。
Require lockfileで導入を強制しても、再利用可能ワークフローの境界は残ります。まず1つで生成、レビュー、オンライン検証を理解すると展開しやすくなります。次の緑のチェックでは、項目の網羅性、来歴、選んだコードのレビューのうち何を確認したのか読み取ってみてください。