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

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 https://github.com/actions/setup-node/issues/325

[gruckion]

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.

Read the comments it sounds like there is a potential work around? But I am unclear on what the work around is. I also don’t see working-directory in the actions.yml or in any open PRs.

What’s the status of this one?

[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! 🙂