GitHub Actions:「Cache not found for input keys」
復元のステップがキャッシュのエントリを探し、見つからなかったので、ジョブはそれ無しで動きます。エラーではなく、ステップは成功します。大事なのはなぜ何も合わなかったかで、たいてい次の5つのどれかです。
見え方
2026年10月、このせいで13分かかったプルリクエストのビルドから(homeboy #17018):
Cache not found for input keys: Linux-cargo-source-v2-8c1ea9e4…-7eb031de…-8f01ff49…, Linux-cargo-source-v2-8c1ea9e4…-7eb031de…-
- 最初のキーが
key、残りがrestore-keysで、書いた順です。エントリのキーがkeyと同じか、どれかの restore key で始まれば合います。 - そのうえで、キーとは関係の無いハッシュの、バージョンも同じでなければなりません(下の3)。
1. キーが変わった
- キャッシュする中身より頻繁に変わるファイルを
hashFiles()している。homeboy では、リリースのたびにCargo.lockのプロジェクト自身のクレートのバージョンが変わり、リリースは1日に何度もありました。pi-setup #151 では、キーがワークフローのファイル全体をハッシュしていたので、コメントの1語を直しただけで、次の実行がすべてを取り直していました。 - 保存のステップが、復元のステップと違うキーを計算した。ozone #11665 では、復元は
maven-repo-d88b…を探し、保存はmaven-repo-0bf0…に書いていました。その時点では、ビルドがtarget/の下に書いたpom.xmlにもhashFiles('**/pom.xml')が合っていたからです。次の実行はまたd88b…を探します。直しは、保存の前にmvn cleanを走らせるものでした。
中身を決めるファイルだけをハッシュし、ビルドの出力は外し、復元のステップが使ったキーで保存し、ぴったりのエントリが無いときに近いものを使えるよう restore key を足します:
- uses: actions/cache/restore@v6
id: restore-cache
with:
path: ~/.m2/repository
key: maven-repo-${{ hashFiles('**/pom.xml', '!**/target/**') }}
restore-keys: maven-repo-
# ... build ...
- uses: actions/cache/save@v6
if: steps.restore-cache.outputs.cache-hit != 'true'
with:
path: ~/.m2/repository
key: ${{ steps.restore-cache.outputs.cache-primary-key }}
2. この実行から読めないスコープにある
- 実行が復元できるのは、自分のブランチとデフォルトブランチのキャッシュ、プルリクエストならベースブランチのものもです。子のブランチや兄弟のブランチ、別のタグのキャッシュは復元できません。
- プルリクエストで保存したキャッシュは
refs/pull/<番号>/mergeに属し、復元できるのはそのプルリクエストの再実行だけです。新しいプルリクエストは、デフォルトブランチが保存したものから始まります。 - なので、デフォルトブランチでそのキーを保存するものが無ければ、プルリクエストは毎回外れます。homeboy では、デフォルトブランチのエントリのキーに、プルリクエストのキーと違う部分がありました。saboteur #922 では、キャッシュを満たすはずのジョブが、作るものがあるときに限って、保存の前にキャンセルされていました。
デフォルトブランチへの push の実行に、プルリクエストが復元するエントリを、同じキーの作り方で保存させます。
3. キーは同じで、バージョンが違う
エントリにはキーのほかにバージョンがあり、復元は restore key のときも含め、同じバージョンのものにしか合いません。toolkit はバージョンを次から計算します:
pathの行を書いたとおりに、順番も込みで。~/.npmと/home/runner/.npmは別のバージョンです。- 圧縮の方式。
zstdの無いランナーやコンテナーは gzip を使い、zstd で保存したエントリを見つけません。 - Windows では Windows 専用の印。保存と復元の両方で
enableCrossOsArchive: trueにしない限り付きます。
ステップのデバッグのログを有効にすると、復元は「Cache not found for version <hash> of keys: ...」も出すので、いまあるエントリのバージョンと比べられます(デバッグのログの有効にし方)。
4. 追い出された
- GitHub は、7日使われていないエントリを消します。リポジトリのキャッシュが上限(変えていなければ 10 GB)を超えると、使われたのが古いものから消えます。
- test-in #430 では、06:48 に保存した 2,910 MB のエントリが33分後には無く、別のジョブが保存した 7,030 MB に押し出されていました。プルリクエストの写しも数に入ります。helion #3799 では、その4つが 10.06 GB のうち 6.2 GB を占めていました。
エントリを減らして小さくする、プルリクエストでは保存しない(保存のステップに if: github.event_name == 'push')、またはリポジトリの Actions の設定で上限を上げます(10 GB を超えた分は課金)。
5. ダウンロードに失敗した
エントリは見つけたのにダウンロードできなかった復元も、同じ行で終わります(helion #3799):
Cache hit for: triton-thirdparty-b200-tileir-0d9283bf49 Received 125829120 of 1547099396 (8.1%), 30.0 MBs/sec ... Failed to restore: The operation cannot be completed in timeout. Cache not found for input keys: triton-thirdparty-b200-tileir-0d9283bf49
1行上を見ます。「Cache hit for」のあとに「Failed to restore」があれば、エントリが無いのではなく、ダウンロードの問題です。
何があるかを見る
gh cache list --key maven-repo- --json key,ref,version,lastAccessedAt,sizeInBytes
refがスコープです。refs/heads/main、または1つのプルリクエストの写しならrefs/pull/123/merge。- キーは合っていて
versionが違うエントリなら、3です。 - 実行が保存したのにエントリがまったく無ければ、4です。
外れたときの cache-hit は空
steps.<id>.outputs.cache-hitは、ぴったり合えば'true'、restore key で合ったときだけ'false'、何も復元しなければ空です。コードは、actions/cache #1466 を挙げて、わざと値を入れていません。- なので
if: steps.cache.outputs.cache-hit == 'false'のステップは、まったく外れたときには動きません。endjin #233 では、ビルドの状態が無いときにジョブを止めるはずの確認が動かず、リリースのビルドが成功のまま何も公開していませんでした。!= 'true'で判定します。 - エントリが無いときにジョブを失敗させるなら、
fail-on-cache-miss: trueにします。ステップは「Failed to restore cache entry. Exiting as fail-on-cache-miss is set. Input key: ...」で止まります。
見分け方
- 「Cache restored from key: ...」は当たりです。「Cache hit for restore-key: ...」は部分的な当たりで、終わりの保存がぴったりのキーで書きます。
- 「Failed to save: Unable to reserve cache with key」は終わりの保存のほうで、復元ではありません(「Unable to reserve cache」)。
失敗したジョブを IntelliJ IDEA から見るなら
Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE(2024.1 以降)のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べ、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro(月 US$1.50・30日の無料試用つき)です。
GitHub と GitHub Actions は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに:「Unable to reserve cache」 · デバッグのログと ACTIONS_STEP_DEBUG · 「No space left on device」 · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English