setup-node restoring cache but still takes a while to yarn

user_954940 0
Viewed 837

So the setup-node github action caches node_modules with this config:

      - uses: actions/setup-node@v2
        with:
          node-version: '14.15.5'
          cache: 'yarn'

I can see it restores a cache.

/home/runner/.cache/yarn/v6
Received 0 of 138278798 (0.0%), 0.0 MBs/sec
Received 113246208 of 138278798 (81.9%), 53.4 MBs/sec
Received 138278798 of 138278798 (100.0%), 55.8 MBs/sec
Cache Size: ~132 MB (138278798 B)
/usr/bin/tar --use-compress-program zstd -d -xf /home/runner/work/_temp/b44b9064-7157-4afd-a342-f81e1005ef1d/cache.tzst -P -C /home/runner/work/app-frontend/app-frontend
Cache restored successfully

But when I do a yarn --frozen-lockfile (we always commit our lockfiles)

I see this output:

Run yarn --frozen-lockfile
yarn install v1.22.17
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
...

and the step still takes 44 seconds.

I'm confused about why this happens.

I implemented my own caching like this:

      - name: Cache Modules
        uses: actions/cache@v2
        with:
          path: '**/node_modules'
          key: ${{ runner.os }}-modules-${{ hashFiles('**/yarn.lock') }}

And now when I run yarn --frozen-lockfile the step completes in 3 seconds and outputs:

Run yarn --frozen-lockfile
yarn install v1.22.17
[1/4] Resolving packages...
success Already up-to-date.
Done in 1.21s.

I'm confused as to why this is. Obviously I'm misunderstanding something about the way something (yarn, setup-node caching, something else?) works.

The goal is to get the build as fast as possible (while being correct, of course). Can anybody help me understand why setup-node is restoring a cache but yarn is still doing 44 seconds worth of work?

yarnpkg github-actions
1 Answers

The built-in cache of setup-node puts the installed packages in the global cache for the package manager used (yarn or npm). The packages will still need to be resolved and installed from the global cache to the local working directory, which, in my case, still took 44 seconds.

My cache, on the other hand, cached the local working directory packages, so they were already installed and resolved locally when I ran it a second time.

user_9549400
Related