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 #325

@kachkaev

Hi @kachkaev ,

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

@kachkaev

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.

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

@kachkaev

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.

@IvanZosimov

👋 @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?

@kachkaev

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

workaround for yarn caches on subprojects: from actions/setup-node#48…

Release 2.0.1 (#95)

Release 2.0.2 (#96)

update gh-pages commands (#98)

gh-pages (#100)

I fixed it with the following setup, but the docker still takes time (2-3m) to build the image, maybe we should apply cache to docker too.

jobs:
  frontend:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Get yarn cache directory path
        id: yarn-cache-dir-path
        run: echo "dir=$(cd client && yarn config get cacheFolder)" >> $GITHUB_ENV

      - name: Cache Dependencies
        uses: actions/cache@v3
        with:
          path: ${{ env.dir }}
          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-

      - name: Setup Node.js and Yarn
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: yarn
          cache-dependency-path: client/yarn.lock
          registry-url: "https://registry.yarnpkg.com"

      - name: Install dependencies
        working-directory: client
        run: yarn install

      - name: Run linter
        working-directory: client
        run: yarn lint

Release 2.0.2 (#101)

Merge branch 'develop'

extend setup-node with proper yarn 3 caching

@kachkaev

Hello @kachkaev, i am going to close this issue because the PR is merged , but please feel free to reopen it or create new issue in case if the problem still exists

chore(deps-dev): bump typescript from 4.9.5 to 5.0.2 (actions#488)

More website fixes (#672)

Update actions/setup-node action to v4 (#56)

Navigation Menu

Repository navigation

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

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

e-korolevskii commented on May 11, 2022

e-korolevskii commented on May 18, 2022

kachkaev commented on May 18, 2022

IvanZosimov commented on May 25, 2022

kachkaev commented on May 25, 2022

IvanZosimov commented on May 26, 2022

10 remaining items

danialdezfouli commented on Mar 13, 2023

dsame commented on Jul 25, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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