Path Validation Error on Cleanup

[NicholasLYang]

Description:
Getting Error: Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved.
on cleanup for action

Action version:
3.7.0

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
Node 18, pnpm 7.12.1

Repro steps:
Example run

Expected behavior:
Clean up with no errors.

Actual behavior:
Path validation error on clean up.

This appears to be new to 3.7.0, because when we pinned the version to 3.6.0, it went away.

[dusan-trickovic]

Hello, @NicholasLYang ! Thank you for creating the issue, we will take a closer look into it and see what can be done :)

[dmitry-shibanov]

Hello @NicholasLYang. We've merged the pull request with possible fix. Could you please try to use actions/setup-node@main to confirm that it works as expected.

For now I'm going to reopen the issue.

[NicholasLYang]

Hi, I'll try it out! Thanks so much for responding so quickly

[NicholasLYang]

Getting a new error here

[dmitry-shibanov]

Hello @NicholasLYang. Thank you for your response. Could you please enable debug for you job and add this step after integration tests:

      - run: |
          cachedPath=$(pnpm store path --silent)
          echo "cached path is $cachedPath"
          [ -d "$cachedPath" ] && echo "Directory $cachedPath exists."

[dmitry-shibanov]

Hello @NicholasLYang, just a gentle ping.

[eddiemonge]

I'm getting the same error Error: Cache folder paths are not retrieved for npm with cache-dependency-path = but using this setup: (no cached-dependency-path and using npm`)

runs:
  using: 'composite'
  steps:
    - uses: actions/checkout@v3
    - uses: actions/setup-node@v3
      with:
        node-version: 18
        registry-url: https://npm.pkg.github.com/
        cache: ${{ hashFiles('**/package-lock.json') && 'npm' || null }}
    - run: npm install --ignore-scripts
      shell: bash
    - run: npm rebuild && npm run prepare --if-present
      shell: bash

I wonder if it has to do with removing the optional part of this check 8170e22#diff-55f15e2366942ad15f71a41ac983f8ce9a9882b28b7fd9082f3a26c799783064L16

[dmitry-shibanov]

Hello @eddiemonge. Could you please attach a failed build? I think you can have the same issue as this.

[jasonkarns]

I was getting similar errors. Started with v3 and cache: yarn (using yarn 3), got:

Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved.

https://github.com/movehq/Hub/actions/runs/5728412193

Which led me to #803 so I tried @main. (ca2d4e0) which then errored:

Cache folder paths are not retrieved for yarn with cache-dependency-path = 

https://github.com/movehq/Hub/actions/runs/5728573485/job/15523437090

[wizardone]

I'm also running into the problem of

Error: Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved

on Cleanup.
Running on @main does not seem to do anything. Has there been any development on new ideas on this topic?

[ajmeese7]

Whenever I tried pinning to v3.6.0, I got a similar but different error:

Post job cleanup.
/home/runner/setup-pnpm/node_modules/.bin/pnpm store path --silent
/home/runner/setup-pnpm/node_modules/.bin/store/v[3](https://github.com/meese-os/meeseOS/actions/runs/6292934770/job/17082829140?pr=156#step:12:3)
Error: Cache folder path is retrieved for pnpm but doesn't exist on disk: /home/runner/setup-pnpm/node_modules/.bin/store/v3

Any ideas on how to proceed from here?

[enchorb]

Getting this after upgrading from yarn 1 to 3. Any solutions?

[GitMurf]

Fyi I had this error when using node v16 and when I changed to v18 it now works with pnpm cache!

Note the other thing I noticed is that it was failing in a workflow of mine that I actually did not run pnpm install with so potentially the issue was that there was no cache created and that is why I was getting this error 🤷‍♂️ ... in case someone else runs into the same scenario.

Anyways, below is working for me now:

name: Test pnpm install and cache

on:
  workflow_dispatch:

jobs:
  test-pnpm-install-and-cache:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [windows-latest, macos-latest]

    steps:
      - name: Checkout the code
        uses: actions/checkout@v3
      - name: Setup pnpm
        uses: pnpm/action-setup@v2
        with:
          version: 8
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: 'pnpm'
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
      - name: Test pnpm list
        run: pnpm list
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Hope this helps someone!

[rjsigma]

I am running into this issue with node 18.17 + yarn 4 once a while. Any debugging I can do to help resolve this issue?

[edenhermelin]

any updates on this one? (using node 18 + pnpm inside a composite action)

[btd1337]

-> build:

Post Use Node.js 18
    Post job cleanup.
    Error: Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved.

name: Workflow de Pull Requests

on:
  pull_request:
    branches:
      - main
      - staging

jobs:
  install_dependencies:
    runs-on: ubuntu-22.04

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Install Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18

      - uses: pnpm/action-setup@v2
        name: Install pnpm
        with:
          version: 8
          run_install: false

      - name: Get pnpm store directory
        shell: bash
        run: |
          echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV

      - uses: actions/cache@v3
        name: Setup pnpm cache
        with:
          path: ${{ env.STORE_PATH }}
          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
          restore-keys: |
            ${{ runner.os }}-pnpm-store-

      - uses: actions/cache@v3
        name: Cache node_modules
        id: cache-nodemodules
        with:
          path: node_modules
          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-
            ${{ runner.os }}-build-
            ${{ runner.os }}-

      - name: Install dependencies
        if: steps.cache-nodemodules.outputs.cache-hit != 'true'
        run: pnpm install

  build:
    runs-on: ubuntu-22.04
    needs: install_dependencies
    steps:
      - uses: actions/checkout@v3
      - uses: pnpm/action-setup@v2
        with:
          version: 8
      - name: Use Node.js 18
        uses: actions/setup-node@v3
        with:
          node-version: 18.x
          cache: 'pnpm'
      - uses: actions/cache@v3
        name: Restore node_modules
        with:
          path: node_modules
          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
      - run: pnpm build

What's wrong here?

[lincolnthalles]

The error is related to the caching layer, not setup-node itself.

As it's a post-setup step, it should just show a warning instead of throwing an error, as this breaks actions that use multiple jobs.

This error can occur if there's an apparently valid cache entry stored for the action and the repo suffered some change after the cache was made, like a folder rename.

Workaround

Running gh cache delete -a, or manually deleting node-cache- cache entries should fix the issue.

Also, editing package-lock.json, yarn.lock or pnpm-lock.yaml by just updating some package will create a new cache key and ignore the older one.

Important

Do not try to be clever and cache node_modules. It uses symlinks/hard links to save space, but caching it can make debugging your actions a living hell, whence setup-node just don't cache it. Node will show weird errors that are hard to make sense, and the action can fail sometimes, but not always (depending on cache invalidation).

Simply configure cache and cache-dependency-path on setup-node and let it cache the global packages that it'll just work.

[TimGuendel]

Workaround

Running gh cache delete -a, or manually deleting node-cache- cache entries should fix the issue.

How to do this inside an action? 🤔

gh: command not found

Does this need to be installed explicitly?

[lincolnthalles]

gh cache

This is the github cli. You run it locally on your machine.
cd to a local copy of the repository and use the gh command.

This specific command will interact with stored workflow caches, like the ones shown on this page. gh cache delete -a is the same thing to access this tab on the browser and click delete (for a repo you have permissions) on each cache.

You shouldn't run this from the action. If you really think clearing the cache all the time is the solution, it's much simpler to just disable the caching entirely by removing cache and cache-dependency-path from the setup-node action.

[Maxim-Mazurok]

I was having this issue when upgrading from v2 to v4

What helped me was to move actions/checkout step to the top

Previously I would only do actions/checkout on a hit miss, so that I can use gh to automatically open issue. This doesn't seem to work with v4 and seemed like it worked with v2.

Here's my action with v2:

# inspired by https://ben.balter.com/2021/12/15/github-actions-website-api-change-notification/

name: Some Check

on:
  schedule:
    - cron: "0 0 * * *" # Runs at 00:00 UTC daily.
  workflow_dispatch: # for manual testing

permissions: write-all

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      # Use cURL to fetch the given URL, saving the response to `some-data.html`
      - name: Fetch data
        run: curl "https://some-url.com" -o some-data.html

      # Optionally, use `jq` to pull one or more fields from the JSON to include in the SMS message
      - name: Parse data
        id: parse_data
        run: echo '::set-output name=someDateHtml::'$(echo some-data.html)

      # Compare the response to the previous run, using a hash of the response as the cache key
      - name: Fetch Cache
        id: cache
        uses: actions/cache@v2
        with:
          path: some-data.html
          key: ${{ hashFiles('some-data.html') }}

      # If there was not a cache hit (meaning the response changed), create issue
      - uses: actions/checkout@v4 # otherwise can't use `gh` command
      - name: Open an Issue
        env:
          GH_TOKEN: ${{ github.token }}
        if: steps.cache.outputs.cache-hit != 'true'
        run: |
          echo "The some data has changed. Please review." > issue-body.txt
          gh issue create --title "some data has changed" --body-file issue-body.txt

Here's my action with v4:

name: Some Check

on:
  schedule:
    - cron: "0 0 * * *" # Runs at 00:00 UTC daily.
  workflow_dispatch: # for manual testing

permissions: write-all

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4 # otherwise can't use `gh` command

      # Fetch the data
      - name: Fetch data
        run: curl "https://some-url.com" -o some-data.html

      # Ensure the file exists and has content before proceeding
      - name: Check file existence
        run: |
          if [ ! -s some-data.html ]; then
            echo "Error: File does not exist or is empty."
            exit 1
          fi

      # Attempt to fetch cache
      - name: Fetch Cache
        id: cache
        uses: actions/cache@v4
        with:
          path: some-data.html
          key: ${{ hashFiles('some-data.html') }}

      # Conditional logic for issue creation
      - name: Open an Issue if data changed
        if: steps.cache.outputs.cache-hit != 'true'
        run: |
          echo "The some data has changed. Please review." > issue-body.txt
          gh issue create --title "some data has changed" --body-file issue-body.txt
        env:
          GH_TOKEN: ${{ github.token }}

Hope this helps someone, cheers!

[Saadi37379]

Please validate my account

[jbmusso]

Our solution (TLDR): remove the .yarnrc.yml file when using pnpm package manager and cache.

We were having the exact same error with pnpm, but in our case there was a .yarnrc.yml file left at the root of the repository that we forgot to remove during the migration from yarn to pnpm. It appears that automated stuffs related to yarn were done during the setup phase that somehow brought confusion related to pnpm cache.

[gauthierm]

In my project, I forgot to add a step to run pnpm install and it caused this error. Making sure I install dependencies fixed the issues.

[adam-azarchs]

I'm getting this with yarn. If I run the action in debug mode, I see during the cache restore step

##[debug]yarn's cache folder "/home/runner/.cache/yarn/v6" configured for the directory "/home/runner/work/my-repo/my-repo"

but then during the cache save I see

'/home/runner/work/my-repo/my-repo//home/runner/.cache/yarn/v6'

So, something isn't properly detecting that the path is absolute, and is inappropriately prepending the working directory. That seems to maybe be a bug in @actions/cache?

[gowridurgad]

Hi @NicholasLYang, The "Path Validation Error" occurs because the specified path for caching does not exist, so no cache is being saved. This is expected behavior when the action has nothing to restore. To reslove this issue, ensure that dependencies are installed before the cleanup step by including an additional step to install them.

- name: Install dependencies
  run: pnpm install

Adding this step to your workflow ensures that there is something to cache, which prevents the path validation error. Attached is a screenshot of the sucessful workflow after installing the dependencies. If you have any other issues or questions, please let us know.

[gowridurgad]

Hi @NicholasLYang, Just a gentle reminder regarding this issue, If you have any updates or need further assistance, Please let us know.

[gowridurgad]

Hi @NicholasLYang, Just a gentle reminder regarding this issue, If you have any updates or need further assistance, Please let us know.

[gowridurgad]

Hi @NicholasLYang, Due to inactivity, I'm going to close this issue for now. Please feel free to reopen this issue or create a new one if necessary. Thank you.