Path Validation Error: Path(s) specified in the action for caching does not exist

[yashsway]

Description:
Getting a strange error in the "Post setup node.js" step in my GitHub workflow. I ran the workflow with debugging enabled and this step fails with this error:

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

Action version:
v3 as uses: actions/setup-node@v3

Platform:

• Ubuntu (ubuntu-latest)
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
pnpm ("packageManager": "pnpm@9.1.2" in package.json at the root of my monorepo)

Repro steps:
This is my GitHub action.

name: Release (Private Packages)
on:
  push:
    branches:
      - master
    paths:
      - ".changeset/**"
      - ".github/workflows/packages-release.yml"
  workflow_dispatch:
env:
  CI: true
  PNPM_CACHE_FOLDER: .pnpm-store
jobs:
  version_or_release:
    name: 'Version and open PR (or) release private packages'
    timeout-minutes: 15
    runs-on: ubuntu-latest
    environment: 'Production - Private Packages'
    steps:
      - name: checkout code repository
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - uses: pnpm/action-setup@v4
      - name: setup node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: 'pnpm'
      - name: setup pnpm store config
        run: pnpm config set store-dir $PNPM_CACHE_FOLDER
      - name: install dependencies
        run: pnpm install --frozen-lockfile
      - name: setup npmrc file to configure pnpm
        run: |
          cat << EOF > "$HOME/.npmrc"
            @mycompany:registry=https://npm.pkg.github.com
            //npm.pkg.github.com/:_authToken=$NPM_PUBLISH_TOKEN
            //registry.npmjs.org/:_authToken=null
          EOF
        env:
          NPM_PUBLISH_TOKEN: ${{ secrets.NPM_PUBLISH_TOKEN }}
          HOME: ${{ github.workspace }}
      - name: create and publish versions
        uses: changesets/action@v1
        with:
          cwd: ${{ github.workspace }}
          version: pnpm run version
          commit: "chore: update package versions"
          title: "Release (Private Packages)"
          publish: pnpm run publish:ci
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          HOME: ${{ github.workspace }}

Expected behavior:
Not really sure what is actually supposed to happen here.

Actual behavior:
With debugging enabled, this is the full trace for the step:

0s
##[debug]Evaluating condition for step: 'Post setup node.js'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Post setup node.js
##[debug]Loading inputs
##[debug]Evaluating: (((github.server_url == 'https://github.com') && github.token) || '')
##[debug]Evaluating Or:
##[debug]..Evaluating And:
##[debug]....Evaluating Equal:
##[debug]......Evaluating Index:
##[debug]........Evaluating github:
##[debug]........=> Object
##[debug]........Evaluating String:
##[debug]........=> 'server_url'
##[debug]......=> 'https://github.com'
##[debug]......Evaluating String:
##[debug]......=> 'https://github.com'
##[debug]....=> true
##[debug]....Evaluating Index:
##[debug]......Evaluating github:
##[debug]......=> Object
##[debug]......Evaluating String:
##[debug]......=> 'token'
##[debug]....=> ''
##[debug]..=> ''
##[debug]=> ''
##[debug]Expanded: ((('https://github.com' == 'https://github.com') && '') || '')
##[debug]Result: '***'
##[debug]Loading env
Post job cleanup.
##[debug]Checking zstd --quiet --version
##[debug]1.5.6
##[debug]zstd version: 1.5.6
##[debug]implicitDescendants 'false'
##[debug]followSymbolicLinks 'true'
##[debug]implicitDescendants 'false'
##[debug]omitBrokenSymbolicLinks 'true'
##[debug]Search path '/home/runner/setup-pnpm/node_modules/.bin/store/v3'
##[debug]Cache Paths:
##[debug][]
Error: Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved.
##[debug]Node Action run completed with exit code 1
##[debug]Finishing: Post setup node.js

[priyagupta108]

Hi @yashsway 👋,
Thank you for reporting this issue. We will investigate it and get back to you as soon as we have some feedback.

[wickkidd]

We're seeing this too for the first time today on yarn berry projects with actions/setup-node@v4.

[legobeat]

Unexpectedly getting the same with a project with a yarn v1 lockfile and cache: yarn, on v3, v4.0.0, and v4.0.4(=v4).

[m9195]

Hi Team,
We are also seeing the same error frequently in Monorepo

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.

This is my github action:-

- name: Set up Node.js
        uses: actions/setup-node@v4.0.4
        with:
          node-version: "18"
          cache: "yarn"

      - name: Set up SSH agent
        uses: webfactory/ssh-agent@v0.5.4
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Login to Azure
        uses: azure/login@v2.1.1
        with:
          creds: |
            {
              "clientId": "${{ env.ARM_CLIENT_ID }}",
              "clientSecret": "${{ env.ARM_CLIENT_SECRET }}",
              "tenantId": "${{ env.ARM_TENANT_ID }}",
              "subscriptionId": "${{ env.ARM_SUBSCRIPTION_ID }}"
            }

      - name: Authenticate with GitHub
        run: git config --global url."https://$MY_GITHUB_TOKEN@github.com".insteadOf https://github.com

      - name: Install Dependencies
        run: yarn install

Runner: Github Hosted

We are installing the required dependencies too , and this issue started to occur few days back.
Previously this was not the case. Kindly help us in resolving this

[mahalakshmi-rekadi]

Hello @yashsway
Thank you for reporting the issue!

The error "Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved" occurs because the caching action cannot find the specified paths. This typically happens when the necessary directories or files do not exist at the time the caching action is executed.

Explanation and Steps to Resolve:

Ensure Dependencies are Installed Before Caching:
The caching action needs the dependencies to be installed first to create the necessary directories and files. In your workflows, the pnpm install step should be executed before setting up caching.

Updated workflow:

env:
CI: true
PNPM_CACHE_FOLDER: .pnpm-store
jobs:
version_or_release:
name: 'Version and open PR (or) release private packages'
timeout-minutes: 15
runs-on: ubuntu-latest
environment: 'Production - Private Packages'
steps:
- name: Checkout code repository
uses: actions/checkout@v3
with:
fetch-depth: 0

  - name: Setup pnpm
    uses: pnpm/action-setup@v4

  - name: Install dependencies
    run: pnpm install --frozen-lockfile

 - name: Setup Node.js
    uses: actions/setup-node@v3
    with:
      node-version: 18
      cache: 'pnpm'
      cache-dependency-path: '**/pnpm-lock.yaml'

  - name: Setup pnpm store config
    run: pnpm config set store-dir $PNPM_CACHE_FOLDER

By ensuring that the dependencies are installed before the caching step, you can avoid the path validation error and successfully cache the pnpm dependencies.

If you are experiencing the same issue with a project that uses a Yarn v1 lockfile and the cache: yarn option, the same principle applies: ensure that the dependencies are installed before the caching step.

I hope this helps! Please let us know if you have any further concerns or questions.

[javiertury]

Ensure Dependencies are Installed Before Caching: The caching action needs the dependencies to be installed first to create the necessary directories and files. In your workflows, the pnpm install step should be executed before setting up caching.

Sorry @mahalakshmi-rekadi but it doesn't make any sense to me. What is the purpose of cache then? If we need to install the packages before activating cache, well, then cache is useless.

[mahalakshmi-rekadi]

Hello @javiertury ,
The purpose of caching in GitHub Actions is to reduce workflow run times by storing dependencies. When dependencies are installed (e.g., using pnpm install), they are cached. This cache is then used in future workflow runs to skip the installation step, provided the cache is up-to-date. If the cache is missing or outdated, the dependencies are reinstalled and the cache is updated accordingly.
The initial installation is essential as it creates the necessary directories and files, which are then cached. This caching mechanism significantly speeds up subsequent runs by restoring the cache instead of reinstalling dependencies, thus avoiding redundant installations.
I hope this helps! Please let us know if you have any further concerns or questions.

[javiertury]

@mahalakshmi-rekadi, some issues are still not clear to me. Suppose that I run your proposed workflow (first install, then setup node with cache for pnpm). Does it mean that next time I run that workflow, the install step will read from cache? Or does it imply that I have to manually edit the action and move the installation step to the end in order to read from the cache? The last case would be very inconvenient, specially if the cache is purged or expired and I have to setup everything manually again every so often.

[submarines-and]

We had this same issue, fixed by updating yarn. Maybe it is the same as for you.

[m9195]

Hi Team, We are also seeing the same error frequently in Monorepo

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.

This is my github action:-

- name: Set up Node.js
        uses: actions/setup-node@v4.0.4
        with:
          node-version: "18"
          cache: "yarn"

      - name: Set up SSH agent
        uses: webfactory/ssh-agent@v0.5.4
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Login to Azure
        uses: azure/login@v2.1.1
        with:
          creds: |
            {
              "clientId": "${{ env.ARM_CLIENT_ID }}",
              "clientSecret": "${{ env.ARM_CLIENT_SECRET }}",
              "tenantId": "${{ env.ARM_TENANT_ID }}",
              "subscriptionId": "${{ env.ARM_SUBSCRIPTION_ID }}"
            }

      - name: Authenticate with GitHub
        run: git config --global url."https://$MY_GITHUB_TOKEN@github.com".insteadOf https://github.com

      - name: Install Dependencies
        run: yarn install

Runner: Github Hosted

We are installing the required dependencies too , and this issue started to occur few days back. Previously this was not the case. Kindly help us in resolving this

Can anyone suggest on this, in our case we are even installing the dependencies, and the failure is only for few of them and not all.
It is like for every 10 workflows run one time the error occurs.
Let me know if anyone has any suggestions on this

[aparnajyothi-y]

Hello Everyone, apologies for the confusion earlier. After a thorough investigation, we discovered that the missing PNPM cache directory (i.e., PNPM_CACHE_FOLDER) was the root cause of the ""Path Validation Error: Path(s) specified in the action for caching does not exist.""

It’s important to note that the absence of the PNPM_CACHE_FOLDER environment variable caused the failure and the job runs successfully even if we remove that variable env: PNPM_CACHE_FOLDER: .pnpm-store .

Potential Root Cause in the Original Workflow:
Missing Cache Directory: The original workflow did not ensure the PNPM cache directory was created before attempting to access it. This led to the path validation error when the caching action tried to locate a non-existent directory.

Changes in the Updated Workflow:
Verification of Cache Directory: A new step has been added to check for the existence of the cache directory. If it’s not found, the directory is created, which prevents errors during the caching process.

- name: Verify PNPM Cache Directory
        run: |
          if [ ! -d ""$PNPM_CACHE_FOLDER/store/v3"" ]; then
            echo ""PNPM cache directory does not exist, creating it.""
            mkdir -p ""$PNPM_CACHE_FOLDER/store/v3""
          else
            echo ""PNPM cache directory exists.""
          fi

The above changes resolved the Path Validation error, allowing the cache to be saved and utilized in subsequent runs. Please see the screenshots for your reference.

Please feel free to reach us in case of any concerns/clarifications needed

[aparnajyothi-y]

Hello @yashsway, Please let us know if the above resolved with the above work around or still have further concerns.

[javiertury]

I tried the solution proposed by @aparnajyothi-y but it didn't work, I get the same errors. For the sake of clarity, this was my workflow

env:
  PNPM_CACHE_FOLDER: .cache/pnpm

jobs:
  publish_container:
    runs-on: ubuntu-latest
    steps:
      -
        name: Check out repository code
        uses: https://github.com/actions/checkout@v4
      - name: Install pnpm
        uses: pnpm/action-setup@v4
        with:
          version: 9
          run_install: false
      - name: Verify PNPM Cache Directory
        run: |
          if [ ! -d "$PNPM_CACHE_FOLDER/store/v3" ]; then
            echo "PNPM cache directory does not exist, creating it."
            mkdir -p "$PNPM_CACHE_FOLDER/store/v3"
          else
            echo "PNPM cache directory exists."
          fi
      - name: Setup package manager cache
        uses: actions/setup-node@v4
        with:
          cache: 'pnpm'
      - name: Setup pnpm config
        run: pnpm config set store-dir $PNPM_CACHE_FOLDER
      - name: Install and build project
        run: |
          pnpm install --frozen-lockfile
          pnpm run build
      ...

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

[aparnajyothi-y]

Hello @javiertury, Thank you for your response. We ran the same workflow, and everything is working fine on our end. Please find the screenshots attached for your reference.

It would be helpful if you could share the reproduction link, as we are unable to replicate the error using the provided workaround.

[javiertury]

We ran the same workflow, and everything is working fine on our end.

@aparnajyothi-y the workflow from your screenshot is not the same I posted, in fact it's quite different. However when I saw those [debug] tags, and I immediately realized they would be of great help in solving this issue. They are enabled by creating an action secret ACTIONS_STEP_DEBUG with value true.

After many hours of debugging I managed to solve the issue

env:
  RUNNER_TOOL_CACHE: /toolcache
  PNPM_CACHE_FOLDER: .cache/pnpm

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      -
        name: Check out repository code
        uses: https://github.com/actions/checkout@v4
      - name: Install pnpm
        uses: pnpm/action-setup@v4
        with:
          version: 9
          run_install: false
      # Optional, the default pnpm store is .pnpm-store if the step below is omitted
      - name: Setup pnpm config
        run: pnpm config set store-dir "$PNPM_CACHE_FOLDER"
      # Makes sure the pnpm store path exists (which is exactly what setup-node cares about)
      - name: Verify PNPM Cache Directory
        run: |
          PNPM_STORE_PATH="$( pnpm store path --silent )"
          if [ ! -d "$PNPM_STORE_PATH" ]; then
            echo "PNPM store directory does not exist, creating it."
            mkdir -p "$PNPM_STORE_PATH"
          else
            echo "PNPM store directory exists."
          fi
      - name: Setup package manager cache
        uses: actions/setup-node@v4
        with:
          cache: 'pnpm'
      - name: Build
        run: |
          pnpm install --frozen-lockfile && pnpm run build

The order of the steps above is very important. All that setup-node cares about is the directory returned by pnpm store path --silent, so in the previous step we must make sure that it exists. Optionally, we can configure the location of its parent directory by pnpm config set store-dir <pnpm cache folder> before the steps mentioned earlier but after pnpm has been installed.

[aparnajyothi-y]

Hello @javiertury, Thank you for sharing your workflow and insights. It seems that your solution is quite similar to the one we suggested earlier. The root cause of the error was the missing PNPM cache directory (PNPM_CACHE_FOLDER), which led to the Path Validation Error: Path(s) specified in the action for caching does not exist.

In our workflow, we ensured that the PNPM cache directory was created before attempting to cache using setup-node, which resolved the issue. Here's a summary of the changes we made as a workaround:

Verification of Cache Directory:
We added a step to check if the PNPM cache directory exists. If it doesn’t, the directory is created, which prevents errors during the caching process:

- name: Verify PNPM Cache Directory
  run: |
    if [ ! -d ""$PNPM_CACHE_FOLDER/store/v3"" ]; then
      echo ""PNPM cache directory does not exist, creating it.""
      mkdir -p ""$PNPM_CACHE_FOLDER/store/v3""
    else
      echo ""PNPM cache directory exists.""
    fi

By ensuring the cache directory exists before caching, we were able to resolve the error. It looks like this solution addresses the issue you're facing as well, with the directory path validation in place.

If you run into any further issues or need more assistance, please feel free to reach out.

[javiertury]

@aparnajyothi-y I appreciate your effort and it was indeed a diagnostic and a good hint, but your workflow snippet/step was far from a full solution to my problem, as well as in a general sense.

Since you never post a complete workflow, it is hard to know in which position to place your snippet and it doesn't work with previous workflows posted on this thread. Given the lack of context, it is natural to fallback to a previous general workflow like the original one postted by @yashsway or the one by @mahalakshmi-rekadi. In any of these cases the path that you propose, $PNPM_CACHE_FOLDER/store/v3, won't work regardless of the position in which I introduce the step. The reason is that on those workflows setup-node comes before pnpm config set store-dir, so when setup-node executes pnpm store path --silent to obtain the path to cache, it receives the default $GITHUB_WORKSPACE/.pnpm-store. Thus, your proposed snippet fails to create the directory that setup-node cares about. Also in your screenshot, you hardcode a path /home/runner/setup-node/node-modules/.bin/store/v3 without any explanation why it works, or explaining how we can obtain a similar working path in more conventional setups.

I think overall you did a good job and your posts would become even more helpful by

• Posting full workflows. Sometimes problems manifest when multiple components interact, so a solution must describe the whole setup.
• Generalizing your solutions so they are applicable to a broad audience. For instance, ensuring your solution does not depend on environment variables having arbitrary values that are not explicitly described.
• Helping people to obtain more information about their setup in relation to the problem. It's highly unlikely that the user's setup coincides with yours, and you may not be able to replicate their setup exactly (or it may not be worth your time), so asking them for logs can be a good compromise. For instance, first we can tell users how to produce debug logs (creating ACTIONS_STEP_DEBUG as a secret with value true) and then we tell users to share them. However, it is perfectly acceptable for users to decline out of security concerns, or to share only redacted versions.

[aparnajyothi-y]

Hello @javiertury, Thank you for your detailed feedback—I really appreciate it.
As a workaround, I’ve hardcoded the $PNPM_CACHE_FOLDER/store/v3 path to ensure the directory is created before setup-node runs, thereby bypassing the default cache directory behavior. However, for a more generalized solution, it would be better to avoid hardcoding paths. Ensuring that the custom cache directory is set up correctly without relying on unspecified environment variables would make the solution more flexible and broadly applicable. The generalized approach you provided resolves the issue of the directory not being created as expected.
Hello @yashsway, @javiertury Please let us know if any further clarification or assistance is needed.