GitHub Actions：ワークフロー依存関係のロックがパブリックプレビューに、タグ参照と実行コミットの分離

同じタグで別のコードが実行される問題

アクションは、ワークフロー内で特定の処理を担う構成要素だ。別のリポジトリのアクションを利用すると、そのコードがワークフローの依存関係になる。ロックせずにタグやブランチでアクションを指定すると、実行時点でその名前が指すコードが選ばれる。

タグはしおりのように別の位置へ動かせる名前で、コミットはある時点のコードの状態を識別する記録だ。ブランチも開発が進むにつれて参照先のコミットが変わる。ワークフローファイルに書かれたタグが同じでも、提供元がタグを移動すれば、次の実行で選ばれるコミットは変わり得る。

従来も、コミットの完全な識別子をワークフローファイルに直接書いて実行対象を固定できた。今回の機能は、人が読みやすいバージョン名を残し、実際に実行するコミットを別のロック記録に収める選択肢だ。

名前を残し、実行するコミットを記録

GitHubのドキュメントによると、ロックファイルにはタグやブランチなどの参照名と、選択したコミットが併せて記録される。適用済みのワークフローは、その後に参照名が別のコードを指しても、記録されたコミットを実行する。

たとえば、あるタグが最初はコミットAを指し、その時点でロックファイルにAを記録したとする。後から提供元が同じタグをコミットBに移しても、ロックを適用したワークフローはAを実行する。これは仕組みを説明するための仮の例であり、実際の実行テストの結果ではない。

ロック記録には、所有者とリポジトリの数値識別子も含まれる。GitHub Actionsは実行時にこれらを確認し、コードの取得先がロック時と同じリポジトリかどうかを検査する。コードのバージョンだけでなく、リポジトリの同一性も確認する仕組みだ。

ロックの範囲には、直接呼び出すアクションだけでなく、そのアクションが利用する依存関係も含まれる。ワークフローファイルに直接書かれたアクションの先に連なる構成要素まで記録するため、レビュー対象も目に見える呼び出し一覧より広くなる。

GitHubは、ロックファイルを導入したリポジトリでは、ワークフローファイルにコミットの完全な識別子を直接書く必要はないと案内している。実行対象の固定をなくすのではなく、固定する場所をワークフローファイルからロックファイルへ移す変更だ。

リポジトリの境界と安全性・再現性の限界

再利用可能なワークフローは、別のワークフローから呼び出せる処理手順のまとまりだ。別のリポジトリにあるこのワークフローの内部依存関係は、その定義元リポジトリのロックファイルが管理する。呼び出し側のファイル一つで相手のリポジトリ内部までロックできるわけではなく、相手側でもロックの導入が必要だ。

ロックしたコミットは、元のリポジトリのブランチ内に存在する必要がある。ロックファイルにコミットを記録するという説明は、どんなコミットでも所在に関係なく実行し続けられるという意味ではない。

GitHubは、ロックが依存関係そのものの安全性を判断するわけではないと明記している。実行コードを固定しても、そのコードの悪意ある動作や脆弱性には別途レビューが必要だ。本記事は発表とドキュメントに基づく説明であり、独立した実行テストやセキュリティ改善の測定結果ではない。

ドキュメントが利点として挙げる再現性も、依存関係のコミット選択という範囲で捉える必要がある。同じコミットを選ぶことは、ビルドに使う材料の一つを固定することであり、結果全体が同じになる保証ではない。実行環境、ダウンロードするパッケージ、外部サービスまで同じになる機能と解釈する根拠はない。

対象プランと導入時の変更点

発表に明記された提供対象は、Enterprise Cloud、データレジデンシー（データの保存地域の指定）を利用するEnterprise Cloud、Team、Freeの各プランだ。

チームはワークフローを一つずつ選ぶか、一括でロック対象に登録できる。ワークフローの選択は適用範囲を定める作業で、各アクション依存関係のロック項目の生成は、その範囲を記録する作業だ。拡張機能がロックファイルとワークフローの変更を生成し、チームは選択したワークフローのすべてのアクション依存関係に項目があることを確認して、両方の変更をまとめてレビューし、コミットする。

確認するファイルは.github/workflows/actions.lockで、生成と維持にはGitHub CLIのgh actions-lock拡張機能を使う。ドキュメントは、このファイルを手動で編集しないよう案内している。記録内のrefはタグやブランチなどの参照名、commitはコミット、owner_idとrepo_idはそれぞれ所有者とリポジトリの数値識別子だ。前述のコミットの完全な識別子はSHAを指す。

レビューでは、タグ名だけでなく記録されたコミットの変更も確認する。同じタグを維持したままロック記録がAからBへ変われば、それは実行対象を変える変更だ。ファイルが生成されたことだけで導入完了とするのではなく、選択したワークフローと生成された依存関係の項目が対応しているかを確認することが重要になる。