v1.8.16 breaks cache miss installs when the yarn cache dir != ~/.yarn/cache (windows, yarn2+, etc.)

[jenseng]

Starting with v1.8.16, we're seeing failures in windows-latest workflows whenever there's a cache miss (i.e. dependencies change ... for cache hits it's still working). This happens on any version of node:

saving NPM modules
Error: Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved.
    at Object.<anonymous> (D:\a\_actions\bahmutov\npm-install\v1\dist\index.js:44373:19)
    at Generator.next (<anonymous>)
    at fulfilled (D:\a\_actions\bahmutov\npm-install\v1\dist\index.js:44239:58)
Error: Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved.

Might be due to a recent underlying change in actions/cache? The same workflow works fine on ubuntu-latest, fwiw. The relevant workflow config is:

  test:
    name: "🧪 Test: (OS: ${{ matrix.os }} Node: ${{ matrix.node }})"
    strategy:
      fail-fast: false
      matrix:
        os:
          - ubuntu-latest
          - windows-latest
        node: ${{ fromJSON(inputs.node_version) }}
    runs-on: ${{ matrix.os }}
    steps:
      - name: 🛑 Cancel Previous Runs
        uses: styfle/[email protected]

      - name: ⬇️ Checkout repo
        uses: actions/checkout@v3

      - name: ⎔ Setup node ${{ matrix.node }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node }}
          cache: "yarn"

      - name: 📥 Install deps
        uses: bahmutov/npm-install@v1

Here's a failing windows run using the latest v1 (v1.8.16). Here's a succeeding windows run using v1.8.15. Apart from that workflow change, the checkouts are identical.

[dhruvdutt]

Facing this issue even on Linux systems.

[muratkeremozcan]

Confirmed.

1.8.15 addresses it https://github.com/muratkeremozcan/cy-react-component-test-examples/actions/runs/2576451291.

Here's the 1.8.16 run with debug: https://github.com/muratkeremozcan/multi-stage-caching/runs/7092543067?check_suite_focus=true#step:4:63.

next, since it complained about zstd, I worked around that by installing zstd, which uncovered this

https://github.com/muratkeremozcan/multi-stage-caching/runs/7092638284?check_suite_focus=true#step:5:70

Error: Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved.
at Object. (/__w/_actions/bahmutov/npm-install/v1.8.16/dist/index.js:44373:19)
at Generator.next ()
at fulfilled (/__w/_actions/bahmutov/npm-install/v1.8.16/dist/index.js:44239:58)

[jenseng]

Here's some more context, this is the change that introduced the new error.

I set up a simpler repo w/ debug logging enabled. Here's a failing install on 1.8.16, here's a passing install on 1.8.15.

What's interesting about the passing one is that the Cache Paths are still empty (whereas on ubuntu-latest they are not), yet in any event it does seem to be caching 33 MB of stuff I misread the output, that's not actually true

[jenseng]

(apologies for accidentally temporarily closing, the wrong button had focus and i hit enter 🤦 )

Based on the output it sees like this new error has actually uncovered a longstanding deeper issue, it seems that 1.8.15 "works" but doesn't actually cache anything on windows, i.e. it uploads an empty archive: Cache Size: ~0 MB (30 B), whereas on ubuntu it seems to have correctly archived the yarn cache: Cache Size: ~0 MB (9948 B)

[jenseng]

Some more context, this might only affect yarn. Here you can see npm install works fine, it correctly finds the .npm dir:

##[debug]Search path 'C:\Users\runneradmin\.npm'
##[debug]Matched: C:/Users/runneradmin/.npm
##[debug]Cache Paths:
##[debug]["C:/Users/runneradmin/.npm"]

[jenseng]

Looks like the yarn cache dir is wrong on Windows (and maybe in other scenarios too)? It's trying to archive C:\Users\runneradmin\.cache\yarn but should actually archive C:\Users\runneradmin\AppData\Local\Yarn\Cache

[jenseng]

I suspect any Linux ones that are failing are likely due to running in different containers with a different yarn setup that what this action is inferring ... seems like the general fix will be to use whatever yarn cache dir points at.

[jenseng]

Any fix should also take into account yarn v1 vs v2/v3, as the mechanism for getting the cache dir is different (yarn config get cacheFolder). In yarn 2/3, note the cache dir is typically relative to the project, i.e. ./.yarn/cache, and it looks like caching is completely broken on yarn3 regardless of the OS.

[jenseng]

Here's another workaround/fix ... As of v2.2, actions/setup-node provides equivalent cache functionality. It seems to handle yarn cache dirs correctly, see verbose output here (cache miss) and here (cache hit).

So if you enable its caching, you can replace your use: bahmutov/npm-install step with something like run: yarn install --frozen-lockfile, for example:

steps:
  - name: Set up node
    uses: actions/setup-node@v3
    with:
      node-version: 18
      cache: yarn
  - name: Install deps
    run: yarn install --frozen-lockfile

[evoactivity]

Also saw this on a linux container. Pinned my version to 1.8.15 for now.

[karlhorky]

@bahmutov I guess you're aware of the issue here? Are you planning on releasing a new patch version that addresses this problem?

Another example of the problem happening (this time only on our Windows test run):

Update bahmutov/npm-install action from v1.8.15 to v1.8.16 by renovate [bot] - upleveled/preflight#270

[bahmutov]

Can you open a pr with a fix and I can merge it quickly please?

…

Sent from my iPhone

On Jul 1, 2022, at 05:43, Karl Horky ***@***.***> wrote:  @bahmutov I guess you're aware of the issue here? Are you planning on releasing a new patch version that addresses this problem? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[evoactivity]

#143 This PR would at least stop peoples pipelines breaking just because the cache is broken.

[karlhorky]

v1.8.17 seems to be passing now: upleveled/preflight#270

Not sure if #143 disabled caching somehow though, since it just seems to turn off error reporting.

I think sometimes GitHub's cache is broken, but this does not appear to be the case affecting #146

It seems like for #146, the issue is more that Yarn caching on Windows was actually broken before.

See this comment and others by @jenseng above:

Looks like the yarn cache dir is wrong on Windows (and maybe in other scenarios too)? It's trying to archive C:\Users\runneradmin\.cache\yarn but should actually archive C:\Users\runneradmin\AppData\Local\Yarn\Cache

So it would be good to verify that this is not the case anymore, and that Yarn v1 caching on Windows runners actually works...

[juninholiveira]

I tried running this action today and got this error too. 1.8.17 is still not saving my cache on the first run. Rolled back to 1.8.15 and it worked 🙏Waiting for a definite fix.

[karlhorky]

@juninholiveira are you sure you're running into the same issue? Can you link to a public repo where this is failing? (or if it's not public, maybe you can post some logs?)

v1.8.16 was causing CI to fail completely (eg. GitHub Actions would stop running further steps) - it wasn't just a problem that this version did not save the cache.

[juninholiveira]

@karlhorky Oh, then no. I didn't test 1.8.16, only 1.8.17 and the build did NOT fail completely, just did not save the cache. So it's a different issue then. 1.8.15 on the other hand saved the cache as expected.