Bug: Only rely on Cache key for hit/misses regardless of Path

[BaseInfinity]

Background

It appears that even though the Cache key being used to store and retrieve the cache is the same, a cache hit never occurs because the path string is different.

Here's a screenshot of two jobs on main in a row with the same cache key...we get a cache miss but successful cache upload in both jobs:

The only thing different here is the path. This leads me to believe that the string to the path is influencing the caching which caught me by surprise and isn't mentioned anywhere in the docs.

I saw this being mentioned in a couple other issues: https://github.com/actions/cache/issues/735#issuecomment-1036402013 https://github.com/actions/cache/issues/638#issuecomment-1002972310

This is a bummer because we currently isolate all builds by commit SHA so our path will always be different even though our key based on hashing yarn.lock doesn't change which makes this module unusable in our current workflow, ie: path: ${{ github.sha }}/**/node_modules will always return a cache miss for any new commit even on the same branch.

Proposal

• Make it clear in the docs that path influences how cache hits/misses
• Allow option to strictly look at the Cache key ONLY for hits/misses, otherwise this is unusable for anyone using dynamic paths for their cache workflows

[BaseInfinity]

One could say this is a bug if the documentation states that caching occurs when cache key is the same, says nothing about the path having to be the same as well.

[dopplershift]

It would be REALLY helpful to have the action print out when it fails due to the path. Right now it says:

Cache not found for input keys: proj-Linux-8.1.1-0

and I just spent a day trying to figure out how that happens but I was also seeing:

Unable to reserve cache with key proj-Linux-8.1.1-0, another job may be creating this cache. More details: Cache already exists. Scope: refs/pull/2529/merge, Key: proj-Linux-8.1.1-0, Version: 37db103cc447fb2a9f90faf2fc822b81d14099bd26899a64836c9e097ec1952c

when it turns out that (somehow) the cache was saved with a path of ~ instead of ~/local. Trying to debug that without a UI to look at cache details (or even an API to list the active caches) was terrible. (Not to mention trying to delete the bad one now is going to be fun...)

[BaseInfinity]

I currently figured a workaround for my solution. You can simply add a symlink step to the current working directory and then use relative paths once again which means static strings for the Key/Path are static once again and don't include the github.sha

ln -snf /home/meow/app-builds/${{ github.sha }} ${{ github.workspace }}/${{ github.sha }}

[TimonLukas]

I currently figured a workaround for my solution. You can simply add a symlink step to the current working directory and then use relative paths once again which means static strings for the Key/Path are static once again and don't include the github.sha

ln -snf /home/meow/app-builds/${{ github.sha }} ${{ github.workspace }}/${{ github.sha }}

Thank you for the solution! I created an action that uses mktemp -d to create a temporary workspace, and wanted to implement caching for a specific resource.

One thing I also stumbled across - don't use path: ${{ symlink }}, as this will cache the symlink itself, but not the files below it. Either specify a file, a deeper path, or a glob.

[pallavx]

Hi @BaseInfinity, we have recently updated our docs to indicate that the caching depends on cache-version, which in turn is based on path.

Hope this makes it clear.