fix: replace setup-node pnpm cache with explicit actions/cache#1060
Merged
Conversation
setup-node@v6 with cache: 'pnpm' fails on cache misses when pnpm is managed by corepack: it computes the store path at setup time (before pnpm install), but the path doesn't yet exist on disk, so the POST step's path-validation check fails and marks the job as failed. Replace with explicit caching: - Remove cache: 'pnpm' from setup-node so it no longer manages pnpm caching itself - Add a 'Get pnpm store directory' step that runs pnpm store path --silent (after corepack has been enabled) to capture the real store path used by the project's pinned pnpm version - Add an explicit actions/cache@v5 step that caches that path, keyed on pnpm-lock.yaml so cache keys stay correct Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes a GitHub Actions CI failure in the “Frontend validation” job by replacing actions/setup-node’s built-in pnpm caching with an explicit actions/cache step that keys off pnpm-lock.yaml, avoiding cache path validation issues when pnpm is Corepack-managed.
Changes:
- Removed
cache: 'pnpm'/cache-dependency-pathfromactions/setup-node@v6. - Added a step to compute the pnpm store path via
pnpm store path --silent. - Added an explicit
actions/cache@v5step to cache the computed pnpm store path.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Per Copilot review: running corepack enable pnpm before actions/setup-node is non-deterministic because setup-node prepends its own Node installation to PATH, which can shadow the corepack shims registered by the earlier step. Running setup-node first ensures corepack enable registers pnpm shims against the Node installation that is actually active for the rest of the job. Also extend the pnpm store cache key to include package.json alongside pnpm-lock.yaml, so a packageManager version bump (which only changes package.json, not the lockfile) correctly invalidates the cache. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The \Frontend validation\ CI job was failing on the \Post Use Node.js 22.x\ step with:
\
##[error]Path Validation Error: Path(s) specified in the action for caching do(es) not exist, hence no cache is being saved.
\\
This happens because \�ctions/setup-node@v6\ with \cache: 'pnpm'\ computes the pnpm store path at setup time (before \pnpm install\ has run). When pnpm is managed by corepack and the cache misses, the store directory doesn't yet exist on disk at that point. The POST step's path-validation then fails and marks the entire job as failed — even though all tests, lint, and build steps passed.
Seen in: https://github.com/dgee2/Menu/actions/runs/26310091099/job/77456532434?pr=1058
Fix
The explicit cache step avoids the path-detection race condition and is the approach recommended by the pnpm docs for corepack-managed pnpm.
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com