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

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]

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