依存関係キャッシュのリファレンス

`cache` アクションの使用

          [
          `cache`アクション](https://github.com/actions/cache)は、キャッシュの復元時に次のシーケンスを試行します。

まず、指定した key との完全一致が検索されます。
完全一致が見つからない場合は、key の部分一致が検索されます。
それでも一致が見つからず、restore-keys を指定した場合、これらのキーに部分一致がないか順番にチェックされます。詳細については、「キャッシュキーの一致」を参照してください。

指定した key との完全な一致があった場合は、キャッシュヒットと見なされます。指定した key と完全に一致するキャッシュがなかった場合は、キャッシュミスと見なされます。キャッシュミスの場合は、ジョブが正常に完了すると、このアクションによって新しいキャッシュが自動的に作成されます。新しいキャッシュでは、指定した key が使用され、path で指定したファイルが含められます。処理方法の詳細については、「キャッシュヒットとキャッシュミス」を参照してください。

既存のキャッシュの内容を変更することはできません。代わりに、新しいキーを使って新しいキャッシュを作成できます。

`cache` アクションの入力パラメーター

key: 必須キャッシュ保存時に作成されたキーとキャッシュ検索時に使用されるキー。変数、コンテキスト値、静的な文字列、関数の任意の組み合わせが使えます。キーの長さは最大で512文字であり、キーが最大長よりも長いとアクションは失敗します。
path: 必須キャッシュまたは復元するためのランナーのパス。
- 1 つのパスを指定することも、複数のパスを別々の行に追加することもできます。次に例を示します。
```
- name: Cache Gradle packages
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
```
- ディレクトリまたは単一ファイルのいずれかを指定できます。glob パターンがサポートされています。
- 絶対パス、またはワークスペースディレクトリに対する相対パスを指定できます。
restore-keys: オプション 代替の復元キーを含んだ文字列。各復元キーは新しい行に配置されます。 key に対するキャッシュヒットが発生しない場合は、キャッシュを検索して復元するために、これらの復元キーが指定された順序で使用されます。次に例を示します。
```
restore-keys: |
  npm-feature-${{ hashFiles('package-lock.json') }}
  npm-feature-
  npm-
```
enableCrossOsArchive: Optional 有効にすると、キャッシュが作成されたオペレーティングシステムとは別に、Windows ランナーがキャッシュを保存または復元できるようにするブール値。このパラメーターが設定されていない場合、既定値は false になります。詳しくは、Actions Cache に関するドキュメントの「Cross OS cache (クロス OS キャッシュ)」を参照してください。

メモ

アクセストークンやログイン資格情報などの機密情報は、キャッシュパス内のファイルに保存しないことをお勧めします。読み取りアクセスを持つ人は誰でも、リポジトリに pull request を作成し、キャッシュの内容にアクセスできます。さらに、リポジトリのフォークも、ベースブランチ上に pull request を作成し、ベースブランチ上のキャッシュにアクセスできます。

`cache` アクションの出力パラメーター

cache-hit: キーに対して完全一致が見つかったかどうかを示すブール値。

キャッシュヒットとキャッシュミス

          `key` が既存のキャッシュと厳密に一致した場合、それは "_キャッシュ ヒット_" と呼ばれ、アクションによってキャッシュされたファイルが `path` ディレクトリに復元されます。

          `key` が既存のキャッシュと一致しない場合 (これは _キャッシュ ミス_ と呼ばれます)、ジョブが正常に完了すると、新しいキャッシュが作成されます。

キャッシュミスが発生した場合、アクションはユーザーが指定した restore-keys の一致も検索します。

```
       `restore-keys` を指定した場合、`cache` アクションは `restore-keys` のリストに一致するすべてのキャッシュを順次検索します。
```
- 完全に一致する場合、アクションはキャッシュ内のファイルを path ディレクトリに復元します。
- 完全なマッチがなかった場合、アクションはリストアキーに対する部分一致を検索します。アクションで部分的な一致が見つかると、最新のキャッシュが path ディレクトリに復元されます。

       `cache` アクションが完了し、ジョブの次のステップが実行されます。

ジョブが正常に完了すると、アクションは path ディレクトリのコンテンツを含んだ新しいキャッシュを自動的に作成します。

キャッシュ一致プロセスの詳細については、「キャッシュキーの一致」を参照してください。

`cache` アクションの使用例

次の例では、package-lock.json ファイル内のパッケージが変更されたとき、またはランナーのオペレーティングシステムが変更されたときに、新しいキャッシュを作成します。キャッシュキーは、コンテキストと式を使用して、ランナーのオペレーティングシステムと package-lock.json ファイルの SHA-256 ハッシュを含むキーを生成します。

YAML

name: Caching with npm
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Cache node modules
        id: cache-npm
        uses: actions/cache@v4
        env:
          cache-name: cache-node-modules
        with:
          # npm cache files are stored in `~/.npm` on Linux/macOS
          path: ~/.npm
          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-
            ${{ runner.os }}-build-
            ${{ runner.os }}-

      - if: ${{ steps.cache-npm.outputs.cache-hit != 'true' }}
        name: List the state of node modules
        continue-on-error: true
        run: npm list

      - name: Install dependencies
        run: npm install

      - name: Build
        run: npm run build

      - name: Test
        run: npm test

name: Caching with npm
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Cache node modules
        id: cache-npm
        uses: actions/cache@v4
        env:
          cache-name: cache-node-modules
        with:
          # npm cache files are stored in `~/.npm` on Linux/macOS
          path: ~/.npm
          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-
            ${{ runner.os }}-build-
            ${{ runner.os }}-

      - if: ${{ steps.cache-npm.outputs.cache-hit != 'true' }}
        name: List the state of node modules
        continue-on-error: true
        run: npm list

      - name: Install dependencies
        run: npm install

      - name: Build
        run: npm run build

      - name: Test
        run: npm test

コンテキストを使ったキャッシュキーの作成

キャッシュキーには、コンテキスト、関数、リテラル、GitHub Actionsがサポートする演算子を含めることができます。詳細については、「コンテキストリファレンス」および「ワークフロー内とアクション内で式を評価する」を参照してください。

式を使用して key を作成すると、依存関係が変更されたときに新しいキャッシュを自動的に作成できます。

たとえば、npm key ファイルのハッシュを計算する式を使用して package-lock.json を作成できます。その場合、package-lock.json ファイルを構成する依存関係が変更されると、キャッシュキーが変更され、新しいキャッシュが自動的に作成されます。

npm-${{ hashFiles('package-lock.json') }}

GitHub は、式 hash "package-lock.json" を評価して最終的な key を導き出します。

npm-d5ea0750

`cache` アクションの出力の使用

          `cache` アクションの出力を使用すると、キャッシュ ヒットやキャッシュ ミスが発生したどうかに基づいて操作を実行することができます。 指定した `key` のキャッシュに完全一致が見つかった場合、`cache-hit` の出力は `true` に設定されます。

上記のワークフロー例では、キャッシュミスが発生した場合に、Node モジュールの状態をリストする手順があります。

- if: ${{ steps.cache-npm.outputs.cache-hit != 'true' }}
  name: List the state of node modules
  continue-on-error: true
  run: npm list

キャッシュキーの一致

          `cache` アクションは、最初にワークフロー実行を含むブランチで、`key` とキャッシュ "_バージョン_" のキャッシュ ヒットを検索します。 ヒットが見つからない場合、`key` のプレフィックス一致を検索し、ヒットがそれでも見つからない場合は、`restore-keys` と_バージョン_を検索します。 それでも現在のブランチでヒットが見つからない場合、`cache` アクションは、既定のブランチで同じ手順を再試行します。 検索中はスコープの制限が適用されることに注意してください。 詳細については、[「キャッシュにアクセスする際の制限」](#restrictions-for-accessing-a-cache)を参照してください。

キャッシュバージョンは、キャッシュの作成時に使用された path と圧縮ツールのメタデータを使って、キャッシュにスタンプを付ける方法です。これにより、使用するワークフロー実行が、実際に圧縮を解除して使用できるキャッシュと一意に一致することが保証されます。詳しくは、Actions Cache に関するドキュメントの「Cache Version (キャッシュバージョン)」を参照してください。

          `restore-keys` では、`key` でキャッシュ ミスが発生した場合に使用する代替復元キーのリストを指定できます。 特定の度合いが強いものから弱いものへ並べて複数のリストアキーを作成できます。 
          `cache` アクションは `restore-keys` を順番に検索します。 キーが直接マッチしなかった場合、アクションはリストアキーでプレフィックスされたキーを検索します。 リストアキーに対して複数の部分一致があった場合、アクションは最も最近に作成されたキャッシュを返します。

複数のリストアキーの利用例

restore-keys: |
  npm-feature-${{ hashFiles('package-lock.json') }}
  npm-feature-
  npm-

ランナーは式を評価し、次の restore-keys に解決します。

restore-keys: |
  npm-feature-d5ea0750
  npm-feature-
  npm-

復元キー npm-feature- は、文字列 npm-feature- で始まるすべてのキーと一致します。たとえば、npm-feature-fd3052de および npm-feature-a9b253ff の両方のキーと復元キーが一致します。最も最近の期日に作成されたキャッシュが使われます。この例でのキーは、以下の順序で検索されます。

       **
       `npm-feature-d5ea0750`
       ** は特定のハッシュと一致します。

       **
       `npm-feature-`
       ** は、`npm-feature-` というプレフィックスのキャッシュ キーと一致します。

       **
       `npm-`
       ** は、`npm-` というプレフィックスの任意のキーと一致します。

検索の優先度の例

key:
  npm-feature-d5ea0750
restore-keys: |
  npm-feature-
  npm-

たとえば、pull request が feature ブランチを含んでいて、既定のブランチ (main) をターゲットとしている場合、アクションは key と restore-keys を次の順序で検索します。

       `npm-feature-d5ea0750` ブランチ内のキー `feature`

       `npm-feature-` ブランチ内のキー `feature`

       `npm-` ブランチ内のキー `feature`

       `npm-feature-d5ea0750` ブランチ内のキー `main`

       `npm-feature-` ブランチ内のキー `main`

       `npm-` ブランチ内のキー `main`

特定のパッケージマネージャ向け `setup-*` アクション

以下に示すパッケージマネージャーをキャッシュする場合、それぞれの setup-* アクションを使用するには、最小構成が必要となります。これにより、依存関係キャッシュが作成され、復元されます。

パッケージマネージャー	キャッシュの setup-* アクション
npm、Yarn、pnpm

          [setup-node](https://github.com/actions/setup-node#caching-global-packages-data)                  |

キャッシュへのアクセスについての制限

アクセス制限を使用すると、さまざまなブランチまたはタグ間に論理境界を作成することで、キャッシュを分離しセキュリティで保護することができます。ワークフロー実行では、現在のブランチまたは既定のブランチ (通常は main) で作成されたキャッシュを復元できます。 pull request に対してワークフロー実行がトリガーされた場合は、ベースブランチで作成されたキャッシュを復元することもできます (フォークされたリポジトリのベースブランチも含む)。たとえば、ブランチ feature-b にベースブランチ feature-a がある場合、pull request でトリガーされたワークフロー実行では、既定のブランチ main、ベースブランチ feature-a、および現在のブランチ feature-b で作成されたキャッシュにアクセスできます。

ワークフロー実行では、子ブランチまたは兄弟ブランチ用に作成されたキャッシュを復元することはできません。たとえば、子ブランチ feature-b 用に作成されたキャッシュに、親ブランチ main でトリガーされたワークフロー実行からアクセスすることはできません。同様に、ベース feature-a を持つブランチ main 用に作成されたキャッシュに、ベース feature-c を持つその兄弟ブランチ main からアクセスすることはできません。また、ワークフロー実行では、異なるタグ名に対して作成されたキャッシュを復元することもできません。たとえば、タグ release-a に対してベース main で作成されたキャッシュに、タグ release-b に対してベース main でトリガーされたワークフロー実行からアクセスすることはできません。

pull request でトリガーされたワークフロー実行によってキャッシュが作成される場合、そのキャッシュは merge ref (refs/pull/.../merge) に対して作成されます。このため、このキャッシュのスコープは制限され、pull request の再実行によってのみ復元できます。ベースブランチ、またはそのベースブランチを対象とする他の pull request では、復元できません。

リポジトリ内の複数のワークフロー実行で、キャッシュを共有できます。あるワークフロー実行でブランチ用に作成されたキャッシュは、同じリポジトリとブランチの別のワークフロー実行からアクセスおよび復元できます。

メモ

オブジェクトはランナーから直接キャッシュから取得されるかキャッシュに格納されるため、Actions ランナーは、AWS S3 や Azure Blob Storage など、GitHub Enterprise Server で構成された Actions オブジェクトストレージに直接接続する必要があります。セルフホステッドランナーは、GitHub Enterprise Server インスタンスが提供するアクセス URL を使用して、BLOB ストレージプロバイダーで認証します。この URL は、BLOB ストレージプロバイダーに有効かつ一時的な認証資格情報を提供します。このプロセスはインスタンス自体によって開始され、オブジェクトストレージへのすべての要求を仲介します。

これは、actions/cache が正しく機能するには、Blob Storage への HTTPS 接続が必要であることを意味します。

すべてのメタデータは、GitHub Actions 内のマイクロサービスであるアーティファクトキャッシュサービスによって管理されます。

キャッシュストレージの詳細については、「外部ストレージの要件」を参照してください。

利用制限と退去のポリシー

GitHub は、キャッシュストレージと保持期間に制限を適用し、ストレージ費用を管理し、悪用を防ぎます。これらの制限を理解することは、キャッシュの使用を最適化するのに役立ちます。

既定の制限

GitHub は、7 日間アクセスされていないキャッシュエントリをすべて削除します。格納できるキャッシュの数に制限はありませんが、リポジトリ内のすべてのキャッシュの合計サイズは制限されています。既定では、この制限はリポジトリあたり 10 GB ですが、この制限はエンタープライズ所有者、組織の所有者、またはリポジトリ管理者が増やすことができます。リポジトリが最大キャッシュストレージに達すると、キャッシュの削除ポリシーにより、最終アクセス日時が最も古いものから最も新しいものの順にキャッシュが削除されて、スペースが作成されます。

この制限を超えると、GitHub は新しいキャッシュを保存しますが、合計サイズがリポジトリの制限を下回るまでキャッシュの削除を開始します。キャッシュの削除プロセスが原因で、キャッシュのスラッシングが発生する場合があります。その場合は、キャッシュが高い頻度で作成および削除されます。これを減らすために、リポジトリのキャッシュを確認し、特定のワークフローを構成してオプトインしたファイルに対する支払い方法を持つユーザーのみが使用できます。「AUTOTITLE」を参照してください。リポジトリのキャッシュサイズ制限を増やすこともできます。詳しくは、「リポジトリのGitHub Actions設定の管理」をご覧ください。

次のステップ

依存関係キャッシュの管理については、「AUTOTITLE」を参照してください。

この記事で