Random Yarn cache error "yarn cache is not found"

[neilime]

Description:

In actions/setup-node, we can observe a random behavior on Yarn cache restoration. Sometime we can see the message "yarn cache is not found". Even if a cache has been created in a previous run.

I don't succeed to identify the context to reproduce the issue, despite many attempts.

Action version:
v3.4.1

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
yarn

Repro steps:

1. Use this action in a nodejs repository having yarn.lock file
2. Run the workflow for the first time
3. Update yarn.lock (by adding a new dependency or updating an existing one)
4. Push to run the workflow a second time
5. See the error message "yarn cache is not found"

Example repository: https://github.com/escemi-tech/test-yarn-cache-is-not-found

Expected behavior:
Yarn cache should be restored once it has be created once even is if yarn.lock file has changed

Actual behavior:

Yarn cache is not restored when yarn.lock file has changed

A potential clue

In documentation, it says "The action follows actions/cache guidelines".

For yarn, actions/cache tells to use it as follow:

- uses: actions/cache@v3
  id: yarn-cache # use this to check for `cache-hit` (`steps.yarn-cache.outputs.cache-hit != 'true'`)
  with:
    path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
    key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
    restore-keys: |
      ${{ runner.os }}-yarn-

In

setup-node/src/cache-restore.ts

Line 39 in 2fddd88

const primaryKey = `node-cache-${platform}-${packageManager}-${fileHash}`;

, it looks like that cache is restored on node-cache-${platform}-${packageManager}-${fileHash} and not on node-cache-${platform}-${packageManager}- as recommended by the documentation.

[dmitry-shibanov]

Hello @neilime. Thank you for your report. I think it is an expected behaviour because the setup-node action uses only primary key. For now I'm going to close the issue.

[ArmorDarks]

@dmitry-shibanov Though, why it's expected behavior, and why not add restore-keys?