`cache: yarn` not working for Yarn 3 (Berry) in a subfolder

[kachkaev]

Description:

When a repo with Yarn Berry is in a subfolder, cache: yarn does not get applied.

Action version:

setup-node@3.1.1

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:

Yarn 3.2

Repro steps:

Configure a pipeline that checks out the Node repo into a subfolder:

    - name: Check out tooling
      uses: actions/checkout@v3
      with:
        path: tooling ## 👈 👀
        repository: example-org/example-tooling-repo

Setup Node, as suggested in the action docs:

    - name: Setup Node
      uses: actions/setup-node@v3
      with:
        node-version: 18
        cache: yarn
        cache-dependency-path: tooling/yarn.lock

Expected behavior:

actions/setup-node correctly launches the right version of Yarn (which is included into the repo). Therefore, the right folder is cached and the follow-up setup is faster.

Actual behavior:

Yarn cache dir is resolved to /home/runner/.cache/yarn/v6. This is because yarn --version is called in the default directory, which is followed by yarn cache dir instead of yarn config get cacheFolder inside tooling. Cache end up empty and so all packages are re-downloaded again each time.

Potential solution:

It’d be nice to pass working-directory down to actions/setup-node (similar to the run task).

Workaround:

     - name: Setup Node
       uses: actions/setup-node@v3
       with:
         node-version: 18
-       cache: yarn
-       cache-dependency-path: tooling/yarn.lock
+        
+    - name: Get yarn cache directory path
+      id: yarn-cache-dir-path
+      run: echo "dir=$(yarn config get cacheFolder)" >> $GITHUB_OUTPUT
+      shell: bash
+      working-directory: tooling
+
+    - name: Restore yarn cache
+      uses: actions/cache@v3
+      with:
+        path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
+        key: yarn-cache-folder-${{ hashFiles('**/yarn.lock', '.yarnrc.yml') }}
+        restore-keys: |
+          yarn-cache-folder-

Cache key is inspired by #325

[e-korolevskii]

Hi @kachkaev ,

We will investigate on that issue and come back to you.

[e-korolevskii]

Hello @kachkaev ,

Thanks for your issue. This is unexpected behavior because you're using binaries located directly in a directory, but the action is running at the root of the repository, so it doesn't see yarn binaries in a subfolder. So the yarn version hasn't changed.
We recommend that you install the required version before restoring the cache.

[kachkaev]

This is unexpected behavior because you're using binaries located directly in a directory, but the action is running at the root of the repository

Yep, that's what happens. Keeping Yarn binary in the project and calling global yarn is a normal thing for Yarn berry. In this case global yarn command finds a local binary and delegates everything to it. Thus, there is no need install the right version of global yarn to get the right behavior.

Running yarn config get cacheFolder returns [project-dir]/.yarn/cache rather than some shared global folder. Even if I install the ‘right’ global Yarn but call it from a wrong cwd, it won't return the correct result. Thus, as far as I understand, the only solution is to have something like:

     - name: Setup Node
       uses: actions/setup-node@v3
       with:
         node-version: 18
        cache: yarn
-       cache-dependency-path: tooling/yarn.lock
+       working-directory: tooling ## proposed option, does not exist at the time of writing

This proposed working-directory option will help find yarn.lock path, so cache-dependency-path won't be necessary. This will also make global yarn delegate everything to [job-dir]/tooling/.yarn/releases/yarn-3.x.x.cjs. The delegated binary will know the right cacheFolder: [job-dir]/tooling/.yarn/cache.

Please let me know if you see other solutions here! 🙂

[IvanZosimov]

Hi, @kachkaev 👋 ! Thanks for popping this issue up! Our action, in fact, doesn't support yarn berry out of the box, but you found the perfect workaround that can be helpful to other customers! I think we can close this issue now because it's not really a bug, but expected behaviour. However, I'd like to ask you to open a new feature request and we will investigate the possibility of adding this functionality to the new releases.

[kachkaev]

👋 @IvanZosimov! Yeah I actually agree with you that this more like a feature request rather than a bug report. Do you know if it’s OK to just change issue labels instead of closing and reopening it?

[IvanZosimov]

Hello, @kachkaev 👋 ! Yes, it's OK, I changed the label by myself, thank you again for contributing 🤟