setup-node: Upgrade to v2.3/v2.4 results in post-setup failure

We are using actions/setup-node v2.2 in Yarn-based monorepo. We attempted upgrade to v2.3 and v2.4, but the updated version fails with error Error: Cache folder path is retrieved for yarn but doesn't exist on disk in post-setup step in workflows that also run yarn install command. (We have a workflow that runs yarn audit without actually installing the dependencies. and an upgrade to v2.3/v2.4 passes there without failures.)

Our usage:

    steps:
    - name: 'Checkout'
      uses: actions/checkout@v2.3.4
    - name: 'Setup Node'
      uses: actions/setup-node@v2.4.0
      with:
        node-version: 14.x
        cache: 'yarn'

Logs from “Setup Node” step (identical for passing and failing builds):

Run actions/setup-node@v2.4.0
  with:
    node-version: 14.x
    cache: yarn
    always-auth: false
    check-latest: false
    token: ***
Found in cache @ /opt/hostedtoolcache/node/14.17.4/x64
/usr/local/bin/yarn --version
1.22.11
/usr/local/bin/yarn cache dir
/home/runner/.cache/yarn/v6
yarn cache is not found

Logs from “Post Setup Node” in successful v2.4 run:

Post job cleanup.
/usr/local/bin/yarn --version
1.22.11
/usr/local/bin/yarn cache dir
/home/runner/.cache/yarn/v6
/usr/bin/tar --posix --use-compress-program zstd -T0 -cf cache.tzst -P -C /home/runner/work/<redacted>/<redacted> --files-from manifest.txt
Cache Size: ~0 MB (258 B)
Cache saved successfully
Cache saved with the key: node-cache-Linux-yarn-abc1f1c083ff490ac797c8966c624b3975d27c522daaed7ed60b66058fca009f

Logs from “Post Setup Node” in failed v2.4 run:

Post job cleanup.
/usr/local/bin/yarn --version
1.22.11
/usr/local/bin/yarn cache dir
/home/runner/.cache/yarn/v6
Error: Cache folder path is retrieved for yarn but doesn't exist on disk: /home/runner/.cache/yarn/v6

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 8
  • Comments: 15 (6 by maintainers)

Commits related to this issue

Most upvoted comments

If cache is enabled in YAML and build doesn’t install any dependencies - nothing to cache and cache feature won’t work properly.

Doesn’t this strip actions/setup-node build steps of their idempotence? That is, actions/setup-node build steps may behave differently based on the success or failure of other steps in the job, whether or not the job has been run before, and/or the results of previous jobs?

If so, I feel we may have lost something valuable here.

In previous version, we skipped such errors silently but starting from 2.4.0, we have decided to fail the builds to notify users that “cache doesn’t work” and user can either fix his build or disable cache.

I personally would prefer the previous behavior, as I don’t want to have to worry about whether or not setting the cache flag on actions/setup-node might cause otherwise successful jobs to fail. I get not wanting to silently swallow “cache doesn’t work” issues — perhaps a clear warning in the job logs is more appropriate than a fatal error?

Here’s a workaround I’m using for now, FWIW:

      # Workaround to avoid Post Use step failures. See: https://github.com/actions/setup-node/issues/317
      - run: mkdir -p /home/runner/.cache/yarn/v6
        continue-on-error: true

Appreciate your continued investment in this project, Dmitry and team! 🙇 🙏

The current behavior is expected and correct. We don’t have plans to change it.

If cache is enabled in YAML and build doesn’t install any dependencies - nothing to cache and cache feature won’t work properly. In previous version, we skipped such errors silently but starting from 2.4.0, we have decided to fail the builds to notify users that “cache doesn’t work” and user can either fix his build or disable cache.

Here’s another workaround (thanks @daniellockyer!) https://github.com/TryGhost/Ghost/commit/aec14e5cf34bbb96720e303c32e1cae3fc884169

       - uses: actions/setup-node@v3
+        env:
+          FORCE_COLOR: 0

Rather than users having to disable colour output for the whole workflow (makes reading logs and diagnosing problems harder), or having to disable it for just the step as shown here, how about actions/setup-node disabling FORCE_COLOR by default, just for its own step?

+1 Seeing the same issue when using version 2.4.0 with npm caching.

Post job cleanup.
/opt/hostedtoolcache/node/14.17.4/x64/bin/npm config get cache
/home/runner/.npm
Error: Cache folder path is retrieved for npm but doesn't exist on disk: /home/runner/.npm

If you’re using NPM (and not Yarn), I modified @byrondover’s solution to make it work for our use case:

      # Workaround to avoid "Post Run actions/setup-node" failures.
      # See: https://github.com/actions/setup-node/issues/317
      - run: mkdir -p /home/runner/.npm
        continue-on-error: true

Hello @khitrenovich. Could you please provide repro steps or public repository ? I’ve tried to reproduce by my own, but it works as expected.

+1 I observed the same problem, and rolled back actions/setup-node@v2.2.0 to prevent the Cache Size: ~0 MB problem.