Use restore-key to find cache, when exact match is not available

[MatthijsBurgh]

Description:
Similar to #410 and #441, but these are closed without any result.
Cache is correctly stored in the Post Setup Node, but not hit in the next run.

Run actions/setup-node@v3
  with:
    node-version: 16
    cache: yarn
    always-auth: false
    check-latest: false
    token: ***
Found in cache @ /opt/hostedtoolcache/node/16.18.0/x64
Environment details
  node: v16.18.0
  yarn: 1.22.19
  npm: 8.19.2
  
/usr/local/bin/yarn --version
1.22.19
/usr/local/bin/yarn cache dir
/home/runner/.cache/yarn/v6
yarn cache is not found

I think this is a combined bug report and feature request. As I checked the code in this action and it just checks cache with one primary key. Maybe additional restore-keys can be provided. This is available in the JS API.

Maybe node-cache-${platform}-${packageManager}- is a good restore-key, which would solve the missing hit with an updated lockfile. This would match the example from the actions/cache docs

Action version:
v3

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
node 14 & 16, yarn

Repro steps:
public repo: https://github.com/nklayman/vue-cli-plugin-electron-builder

Expected behavior:
When lockfile is updated, it should hit the most recent cache in that branch scope.

Actual behavior:
When lockfile is updated, it doesn't hit any cache.
Updated lockfile, no cache hit: https://github.com/nklayman/vue-cli-plugin-electron-builder/actions/runs/3481884289
Same lockfile, cache hit: https://github.com/nklayman/vue-cli-plugin-electron-builder/actions/runs/3487432460

[dmitry-shibanov]

Hello @MatthijsBurgh. Could you please rename the issue because it is not a bug but a feature request.

[MatthijsBurgh]

Hello @MatthijsBurgh. Could you please rename the issue because it is not a bug but a feature request.

Done

[dsame]

Hello @MatthijsBurgh,
uncontrolled use of the previous cache causes endless grow of the cache when the new versions of the packages are added to the cached npm directory.

The experience with setup-java showed the use of restore-keys was not appropriated. As a result i had either to deny the PR or request an optional input to explicitly enable the restore-keys in order make sure the user of action knows that he is doing.

[MatthijsBurgh]

@dsame Thanks. I will take this into account. I will keep you updated about I will do next.

[ramblingenzyme]

It might be worth changing the cache key to include an indication of which files are being hashed.

We have internal repos where we use setup-node with different paths passed to "cache-dependency-path" and adding the restore key as implemented in #628 might load a previous cache for a different set of dependencies, i.e. as useful as not having restore-keys at all.

[MatthijsBurgh]

@ramblingenzyme When these are different actions, it uses different caches. I don't see a very straight forward solution to your problem. As the action supports more than just a single file path:

description: 'Used to specify the path to a dependency file: package-lock.json, yarn.lock, etc. Supports wildcards or a list of file names for caching multiple dependencies.'

So if you have any idea to solve this robustly. Please let me know. Otherwise going for the solution of manual enabling this as mentioned by @dsame would not affect your situation for worse.

[dsame]

@ramblingenzyme i advise you to solve your problem with the https://github.com/actions/cache action that can be turned for your specific case.

Will this suggestion work for you?

[dsame]

@ramblingenzyme @MatthijsBurgh i am going to close this issue due to inactivity, but please feel free to reopen it on create new one in case if the problem still exists

[MatthijsBurgh]

@dsame I still have the PR open. I will probably work on it during the Christmas break.