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

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.