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

[khitrenovich]

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

[adrienjoly]

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

[jjoynsonerwin]

+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

[dmitry-shibanov]

Hello everyone. Thank you for your report. The action on post-step fails If caching directory does not exists, that is why it has nothing to cache. The action throws an error to prevent saving empty folder.

[dmitry-shibanov]

Just a gentle ping.

[khitrenovich]

Just a gentle ping.

Frankly, I was patiently waiting for a fix... Are you expecting us to do something about it? I don't think we can, since the post-step is not something the action users have any control over.

[dmitry-shibanov]

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.

[byrondover]

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! 🙇 🙏

[khitrenovich]

@dmitry-shibanov Finally, I had a chance to dive a bit deeper into the issue and add some debugging to the action upgrade PR. I see that Yarn cache exists, but post-setup is unable to find it (as you can see on the screenshot below). How do you suggest to proceed with that?

[dmitry-shibanov]

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

[khitrenovich]

@dmitry-shibanov I was able to eliminate the failure after removing

env:
  FORCE_COLOR: true

setting from the job that was failing in the upgrade PR. My guess would be that the action relies on running terminal commands and parsing the output, which might be affected by the terminal settings. Removing the setting may provide a workaround, but making this a permanent limitation will be pretty inconvenient.

Here is the minimal workflow that will reproduce the issue on any Yarn-based repository:

name: Setup Node Test

on:
  workflow_dispatch:
  pull_request:

env:
  FORCE_COLOR: true

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - name: 'Checkout'
      uses: actions/checkout@v2.3.4
    - name: 'Install Node.js'
      uses: actions/setup-node@v2.4.1
      with:
        node-version: 14.x
        cache: 'yarn'
    - name: 'Install dependencies'
      run: |
        yarn install --frozen-lockfile

[dmitry-shibanov]

Hello @khitrenovich. Thank you for your response. I think it's known problem. We had a similar issue. Please take a look and feel free to contact us if you have any questions.

[khitrenovich]

Oh, good to know. Thank you for the reference!

[oscard0m]

Hello @khitrenovich. Thank you for your response. I think it's known problem. We had a similar issue. Please take a look and feel free to contact us if you have any questions.

Hi @dmitry-shibanov, considering this is a known problem, do you would have sense to revisit this and prevent user's using FORCE_COLOR: 1 or at least provide a warning/error message when using it? If so, I would be happy to draft a PR for it.

[Blackbaud-SteveBrush]

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

[hugovk]

Here's another workaround (thanks @daniellockyer!) TryGhost/Ghost@aec14e5

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