ロックファイルを要求すると、各チームに独自のプラクティスの採用を求めることなく、すべてのワークフローが検証済みのコードを実行するという一貫した監査可能な保証が提供されます。 概要については、「ワークフロー依存関係のロックファイル」を参照してください。
このガイドは、選択したリポジトリでパイロットを実行し、ロックファイルを最新の状態に保つために自動化を設定するのに役立ちます。 ロックファイルが意図したとおりに動作していて、開発者の負担にならないことを確信している場合は、Require lockfile ポリシーを適用できます。
Prerequisites
ワークフロー ロックファイルを適用し、ロックファイルを最新の状態に保つためのプロセスを作成する前に、ロックファイルがリポジトリに存在している必要があります。 手順については、リポジトリのワークフローでのアクションの依存関係のロック を参照してください。 ロックファイルを作成するために管理者である必要はありません。 リポジトリへの書き込みアクセス権を持つすべてのユーザーがこれを行うことができるため、ポリシーを一元的に適用する前に、導入対応を個々のチームに委任できます。
ワークフローが他のリポジトリから再利用可能なワークフローを呼び出す場合は、それらのソース リポジトリもオンボードされていることを確認します。 呼び出し元リポジトリのロックファイルにはそれらが含まれていません。 呼び出された再利用可能なワークフローが独自のリポジトリにオンボードされていない場合は、[ ロックファイルの要求 ] ポリシーによって呼び出し元ワークフローの実行がブロックされます。
1. "ロックファイルを必須にする" ポリシーを試験導入する
重要
ポリシーのEvaluateモードは、GitHub Enterprise Cloudでのみ使用できます。 対象となるすべてのワークフローでロックファイルを最新の状態に保つシステムが整っていると確信できるまで、Active モードでこのポリシーを有効にしないでください。
[ロックファイルを必須にする] ポリシーは、リポジトリのロックファイルに追加されていないターゲット ワークフローの実行をブロックします。これには、uses:依存関係のないワークフローも含まれます。
すべてのリポジトリでこのポリシーを適用する前にパイロットを実施してください。 次の手順に従います。
- lockfiles にオンボードされている特定のリポジトリにポリシーのスコープを設定します。
- すべてのワークフローがオンボードされ、新しいワークフローをオンボードするプロセスが自動化されるまで、ロックファイルにオンボードされている特定のワークフローをターゲットにします。
- まず、ポリシーを評価モードで実行し、ポリシーの分析情報で結果を分析します。
Require lockfile は、アクションを完全長のコミット SHA にピン留めすることを必須にする とは別のポリシーです。 ロールアウト中は両方を有効にしておくことができます。 ポリシーを構成し、2 つがどのように連動するかを確認するには、GitHub Actions ワークフローの実行の管理 を参照してください。
2. ロックファイルを最新の状態に保つ
強制適用は、ロックファイルが最新の状態に保たれている場合にのみ機能します。 開発者がワークフローを作成または編集するたびにロック コマンドを実行する必要がないように、自動化を追加します。
次のセクションでは、開発ライフサイクルのさまざまな時点で古いロックファイルを防ぐ方法の例を示します。
- Dependabotを有効にして、ファイルを最新の状態に保ちます。
- ロック コマンドを実行し、pull request の必須要件の一環として検証するワークフローを作成します。
Dependabot バージョンの更新
Dependabot がアクションのバージョンをバンプすると、同じプル要求で一致するロックファイル エントリが再生成されます。
の依存関係を管理するようにしておけば、それ以外の構成は必要ありません。 「Dependabot でアクションを最新に保つ」を参照してください。
Dependabot は、ロックファイル エントリがまだないワークフローをオンボード しないため 、このオプションでは、拡張するのではなくカバレッジが維持されます。
専用ワークフローまたは Copilot
ユーザーがワークフローを追加または編集すると、ロック コマンドを実行する別のワークフローを実行します。
.github/workflows/**および任意のaction.ymlまたはaction.yamlファイルへの変更に対してワークフローをトリガーし、次の 2 つのジョブを持たせます。
- プッシュ時にロックファイルを再生成し、結果をコミットする 更新 ジョブ。 このジョブには
contents: writeアクセス許可が必要です。また、ブランチ保護ルールまたはルールセットでは、ワークフローが実行されるブランチにプッシュする GitHub Actions を許可する必要があります。 ロックファイルに書き込むにはworkflowOAuth スコープが必要であるため、ツールにそのスコープがあることを確認してください。 - プルリクエストで実行する****
gh actions-lock --verifyジョブ。 ロックファイルが古い場合、これはエラーで終了し、必要なチェックに役立ちます。
すぐに使用できるワークフローの例については、 リポジトリのgh-actions-lockを参照してください。
Copilotを使用してワークフローを編集する場合は、同じ変更セット内のロックファイルを再生成するように設定することもできます。
gh-actions-lock スキルと エージェントのスキル を参照してください。
3. ロックファイルの変更のレビュー プロセスを設定する
ロックファイルは、だれかが差分を読み取った場合にのみセキュリティコントロールです。 変更されたコミット SHA は、具体的には、ワークフローが実行するコードが変更されたことを示します。
- ビルド セキュリティを担当するチームにレビューが自動的に要求されるように、
.github/workflows/actions.lockファイルにCODEOWNERSを追加します。 「コードオーナーについて」を参照してください。 - コード所有者からの承認を要求するように、ブランチ保護規則またはリポジトリルールセットを構成します。
- レビュアーに何を探すべきかを伝えます。 詳しいガイダンスについては、「リポジトリのワークフローでのアクションの依存関係のロック」を参照してください。
4. ポリシーを施行する
ロックファイルが設定されていて、最新の状態が維持されることを確信している場合は、ロックファイルが必要 ポリシーの適用状態を アクティブ に変更します。 オンボードされたすべてのリポジトリとワークフローが対象になっていることを確認します。
重要
ロックファイルを必須にするがアクティブの場合、同じリポジトリ内の他のワークフローがオンボードされている場合でも、そのリポジトリのロックファイルにオンボードされていない対象のワークフローはすべてブロックされます。 ポリシーをアクティブ化する前に、対象となる各リポジトリでgh actions-lock --verifyを実行するか、評価モードでポリシー分析情報を確認して、対象となるすべてのワークフローがカバーされていることを確認します。
手順 2 の検証はそのままにしてください。 このポリシーは、有効なロックファイルを持たないワークフロー実行をブロックします。 これに対し、検証チェックでは、pull request の作業中にロックファイルが古くなっていることを投稿者に通知します。