リポジトリのワークフローでのアクションの依存関係のロック

ワークフローの依存関係をロックすると、参照するアクションに最初に確認されたものと同じコードが含まれていることが保証されます。 詳細については、「ワークフロー依存関係のロックファイル」を参照してください。

1. アクションの参照先を確認する

ロックファイルを作成すると、現在の分岐またはタグ参照に基づいて依存関係がコミットにピン留めされます。 固定したいバージョンがこれらのバージョンであることを確認します。

ワークフロー内の各 uses 参照が、サポートされている現在のバージョンのアクションを指していることを確認します。 ベスト プラクティスについては、セキュリティで保護された使用に関するリファレンス を参照してください。

ワークフローのいずれかが別のリポジトリで再利用可能なワークフローを呼び出す場合は、それらの参照も確認してください。 再利用可能なワークフローの依存関係は、再利用可能なワークフローが定義されているリポジトリのロックファイルによってカバーされます。 組織が共有ワークフローを維持している場合は、まずそれらのリポジトリをオンボードすることをお勧めします。 「ワークフロー構成の再利用」を参照してください。

DependabotでGitHub Actionsの依存関係を管理することをお勧めします。 まだ有効になっていない場合は、ロックファイルを作成する前に有効にします。 「Dependabot でアクションを最新に保つ」を参照してください。

2. actions-lock 拡張機能をインストールする

1. GitHub CLI をインストールします。

2. 拡張機能をインストールします。

gh extension install github/gh-actions-lock

gh extension install github/gh-actions-lock

3. ロックファイルを生成する

リポジトリのルートから、引数なしで拡張機能を実行します。 .github/workflows/下のすべてのワークフローがスキャンされ、解決可能な各アクションがコミット SHA にピン留めされ、ロックファイルが書き込まれます。

gh actions-lock

gh actions-lock

ディレクトリ全体ではなく 1 つのワークフローをオンボードするには、そのパスを渡します。

gh actions-lock .github/workflows/ci.yml

gh actions-lock .github/workflows/ci.yml

ローカル パス アクションがサポートされていないためにワークフローがスキップされたと拡張機能から報告された場合は、そのワークフローの uses: ./… 参照が実際のアクション ファイルに解決されなかったことを意味します。 ローカル パスは、それらを含むファイルのディレクトリ ではなく、リポジトリ ルートから解決されるため、そのファイルの横では正しく見えるパスでも解決されない可能性があります。 パスを修正し、コマンドを再度実行してください。

すべてのオプションを確認するには、gh actions-lock --help を実行します。

4. 変更を確認してコミットする

拡張機能はロックファイルだけでなく他のファイルも変更するため、コミットする前に完全な差分を確認してください。 また、ワークフロー内の参照 uses も、解決された特定のバージョンに書き換えるので、octo-org/deploy-action@v3 などの参照が octo-org/deploy-action@v3.1.0 になる可能性があります。 これにより、解決先のコミットを変更することなく、参照がより具体的になります。

リポジトリ、組織、または企業が指定したアクションのみを許可する場合は、コミットする前に許可リストを確認してください。 ワークフローがオンボードされると、ロックされたコミット SHA に対して許可リストがチェックされます。タグは別のコードを指すように変更できますが、ロックされた SHA は変更できないためです。 タグにピン留めされたエントリ ( actions/checkout@v6など) が一致しなくなりました。 代わりにワイルドカードまたは完全コミット SHA を使用してください。 「リポジトリのGitHub Actions設定の管理」を参照してください。

自身のリポジトリ内のアクションへの参照も、ワークフローとリポジトリ内のuses: $/…ファイルの両方で、action.ymlから同等のuses: ./…に書き換えられます。 $/…参照は常に実行中のコミットに解決されるため、本質的に固定され、ロックファイル エントリは必要ありません。

5. ロックファイルを最新の状態に保つ

リポジトリのワークフロー ファイルとセキュリティ更新プログラムを使用して、ロックファイルを最新の状態に保ちます。

1. 依存関係を変更したら拡張機能を再実行してください。 uses依存関係を持つワークフローを追加したり、既存のワークフローで gh actions-lock 依存関係を追加または削除したりするたびに、uses をもう一度実行します。

2. バージョン更新は Dependabot に任せます。 オンボードしたワークフロー内でDependabotがアクションのバージョン更新を開くと、同じプル要求内の一致するロックファイル エントリも再生成されるため、ワークフロー ファイルとロックファイルが乖離することはありません。

Dependabot は、ワークフローをオンボードしてくれません。 ロックファイル エントリのないワークフロー内の依存関係を更新した場合、オンボーディングが必要と報告されるだけです。

1. 移動した参照を再解決します。 mainやv3など、ブランチまたは部分バージョンへの参照はロックファイルから信頼され、通常の実行では再解決されません。 タグが別のアップストリーム コミットを指しているために拡張機能がエラーを報告する場合は、最初にアップストリーム リポジトリの履歴を確認してください。 移動が有効な場合は、gh actions-lock --relockを使用して参照を再解決します。 アップストリーム リポジトリで強制プッシュまたは削除されたなどの理由で、最初にロックしたコミットにまったく到達できなくなった場合でも、--relock はエラーを報告します。 新しいコミットを受け入れるには、gh actions-lock --relock --accept-movedを実行してください。

ロックファイルの変更を確認

他の依存関係の変更と同様に、ロックファイルの変更を確認します。

• 変更内容 commit は、ワークフローで実行されるコードです。 他の依存関係のバージョン更新と同じように扱います。
• 変更された owner_id または repo_id 項目 はまれです。 つまり、その名前の背後にあるリポジトリは最初にロックしたリポジトリではないため、マージする前に調査してください。

ロックファイルが間違っているように見える場合は、ワークフロー ファイルを修正し、ロックファイルを再生成してください。 ロックファイルを手動で編集しないでください。

次のステップ

リポジトリのロックファイルを生成したら、開発者がコマンドを実行することを覚えておく必要なく、それが確実に適用され、常に最新の状態に保たれるようにします。 「アクションの依存関係に対するロックファイルの強制」を参照してください。