Cache entry from default branch considered out of scope for reusable workflow run on tag

[SanjayVas]

According to Restrictions for accessing a cache:

Workflow runs can restore caches created in either the current branch or the default branch (usually main).

I have a reusable workflow that is called from a workflow that runs on a tag ref. It's not finding the cache entry from the default branch (main in my case).

##[debug]No matching cache found for cache key 'cache-trivy-2024-10-29', version 'cfdc2bcf67bb1c3559bbfba62a7ed98abe2868ecc65f79ee627e58280adbf4d3 and scope refs/tags/nightly/20241028.1. There exist one or more cache(s) with similar key but they have different version or scope. See more info on cache matching here: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#matching-a-cache-key 
##[debug]Other caches with similar key:
##[debug]Cache Key: cache-trivy-2024-10-29, Cache Version: 07dc9f6516584e901e644e11f92897f94dbdb6b82f1dda2bb2c3e7fd20bb931a, Cache Scope: refs/heads/main, Cache Created: 2024-10-29T05:13:41.6566667Z

Both workflows run on ubuntu-latest, so this should not be a cross-OS issue.

[SanjayVas]

I think I figured this out. The GitHub Actions cache version includes the path and does not disambiguate equivalent paths. Therefore the relative path .cache/trivy-cache results in a different version than the absolute path /home/runner/work/cross-media-measurement/cross-media-measurement/.cache/trivy.

[ulidtko]

I'm also struggling with this.

On a (non-default) branch release/7.8, I've got a workflow run with actions/cache (v4.1.2) saying:

Cache saved with key: CI-deps-v0||lts-22.20||59dbd1d2726b5396d15660895bdbfa6ade3bf971f197c99c9372255fd0e439c7

But soon after, when the tip commit of this branch gets tagged, triggering another run, actions/cache says:

Cache not found for input keys: CI-deps-v0||lts-22.20||59dbd1d2726b5396d15660895bdbfa6ade3bf971f197c99c9372255fd0e439c7, CI-deps-v0||lts-22.20||, CI-deps-v0||

This cache is absolutely there, I can see it on https://github.com/org/repo/actions/caches URL.

How do I get this to work? Tag-triggered workflow to pick up cache created on the same branch?

@SanjayVas did you figure it out? I don't think relative/absolute paths is relevant; in my case it is a "non-reusable" workflow yaml, so the with.paths specified are exact same between store & restore.

Dear @Link-, @jww3, any insight from you as the last releasers?

[jtristano]

I have the same problem

gh actions-cache list
Total caches size 25.19 MB

Showing 3 of 3 cache entries in divergent3d/design-app-nx-plugin

cache-name  12.59 MB  refs/tags/0.0.35             2 minutes ago
cache-name   12.59 MB  refs/tags/0.0.34             8 minutes ago
cache-name   12.59 MB  refs/heads/my_branch 11 minutes ago

The cache has limited use and will bloat if I need to create it upon every release

[SanjayVas]

@SanjayVas did you figure it out? I don't think relative/absolute paths is relevant; in my case it is a "non-reusable" workflow yaml, so the with.paths specified are exact same between store & restore.

Yes. My issue was indeed that the workflow that saves the cache used the relative path, whereas the action that restores the cache used the absolute path. Since I didn't write the action, I updated my saving workflow to use the absolute path as well. This resolved the issue for me.

[ulidtko]

Well, I believe the issue is much wider, and not related to paths.

In particular, because what helped me was pinning to 4.0.2:

-      uses: actions/cache@v4
+      uses: actions/cache@v4.0.2 # pinned due to https://github.com/actions/cache/issues/1491

This implies that somewhere in v4.0.2..v4.1.2 a new bug was released.

Steps to reproduce

• have a tag-triggered workflow using actions/cache

Expected result

Cache works: can and does restore existing cache entries.

Actual result

Cache not found for input keys

[pkepa-c8y]

We also have a problem with getting the cache from the default main branch.

Update of cache looks like this and It is done on the default main branch via cron.

     - name: Cache DBs
        uses: actions/cache/save@v4
        with:
          path: ${{ github.workspace }}/.cache/trivy
          key: cache-trivy-${{ steps.date.outputs.date }}

Error:

##[debug]Resolved Keys:
##[debug]["cache-trivy-2024-11-29","cache-trivy-"]
##[debug]Checking zstd --quiet --version
##[debug]1.4.8
##[debug]zstd version: 1.4.8
##[debug]Resource Url: https://acghubeus1.actions.githubusercontent.com/M6NJow4UHymyf4TLHNvio2UC1SZrO84VocFZLFsYGxYq1TCGis/_apis/artifactcache/cache?keys=cache-trivy-2024-11-29%2Ccache-trivy-&version=d5988625b0a42be8b506c17c1f92f9afe0f75ac7b29c3434b3f3d8c5e908d3a0
##[debug]Resource Url: https://acghubeus1.actions.githubusercontent.com/M6NJow4UHymyf4TLHNvio2UC1SZrO84VocFZLFsYGxYq1TCGis/_apis/artifactcache/caches?key=cache-trivy-2024-11-29
##[debug]No matching cache found for cache key 'cache-trivy-2024-11-29', version 'd5988625b0a42be8b506c17c1f92f9afe0f75ac7b29c3434b3f3d8c5e908d3a0 and scope refs/heads/trivy_cache_test. There exist one or more cache(s) with similar key but they have different version or scope. See more info on cache matching here: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#matching-a-cache-key 
##[debug]Other caches with similar key:
##[debug]Cache Key: cache-trivy-2024-11-29, Cache Version: 8f58c66a22afa34cd169e0a37af6dc8721535ebdeb355c04c644ff2177efde7d, Cache Scope: refs/heads/main, Cache Created: 2024-11-29T00:33:55.01Z
##[debug]Failed to delete archive: Error: ENOENT: no such file or directory, unlink ''
Cache not found for input keys: cache-trivy-2024-11-29, cache-trivy-

Cache is available on the list:

Point out what we are doing wrong because at this moment we have run out of ideas...

[graemechristie]

I'm also seeing these case misses with the trivy action. The actions/cache version is set by the trivvy action so it is not something we can update (i.e. to v4.0.2 as per above) without forking thier action .. was there ever any resolution to this ?

[ulidtko]

Hey @graemechristie, no -- the issue stands open. As above, in my case **downgrading** to v4.0.2 (not the latest) was viable workaround.

[ulidtko]

Also reproduces on actions/cache@v3.4.0:

— and yet, the action claims Cache not found for input keys: