Moving the upload to just after the install left one window open: pnpm runs a
package's lifecycle scripts during the install, so an allow-listed dependency
can still append a record claiming some other lockfile passed verification, and
the upload would publish it. Writing pnpm's own record after those scripts
would not help — the log is appended to, so the forged record survives whatever
pnpm writes next to it.
What does distinguish the two is shape: an install appends its own verdict and
leaves earlier records untouched. So the log is uploaded only when every record
that predated the install is still there, and no more records were added than
there were installs. Both failure modes cost a re-verification in the next job
and nothing else, which is also the price of pnpm compacting the log past a
thousand records — rare enough in CI, where a job restores at most one record.
The previous commit listed a dependency's own scripts among the things that
run after the install, which is where they do not run: pnpm executes them
during the install, ahead of the upload, so they stay inside the window rather
than being closed out of it. What keeps that narrow is that pnpm refuses to
run them at all — `ERR_PNPM_IGNORED_BUILDS` — unless the repository
allow-lists the package, and such a package can already run code in the job.
Saving in the post step left the whole job between the install and the upload.
Anything running in that window — the job's tests, its build, a dependency's
own install scripts — can rewrite the log on disk, and the job's own cache
write would then publish a record claiming some other lockfile passed
verification, for every later job to restore and trust. No cache credentials
needed: the attacker rides the write the job performs anyway.
The log is complete the moment the install finishes, so it is uploaded there.
The post step still covers a job that installs in a step of its own, where
that is the first point the log is known to be final; the save is idempotent
across the two, and the process-local flags exist because main and post do not
share state within a run.
The log is under a kilobyte and pnpm writes it on every install, not only
where supply-chain policies are configured: the integrity and tarball-URL
checks are unconditional. A job that starts without it re-checks every
lockfile entry against the registry — on a ~2000-entry lockfile with a warm
store, 13.5s vs 1.5s with `minimumReleaseAge` and `trustPolicy` configured,
and still 6.7s vs 1.6s with no policies at all.
Tying that to the `cache` input made the common case slow for no saving worth
counting, so the log is now restored and saved on its own key whether or not
the store is cached. `cache` goes back to meaning what its name says.
pnpm v11 and newer verify every lockfile entry against the configured
supply-chain policies (`minimumReleaseAge`, `trustPolicy`, ...) and memoize
the verdict in `<cacheDir>/lockfile-verified.jsonl`. The action cached only
the store, so every job started with that verdict missing and re-checked the
whole lockfile against the registry — on typescript-eslint's repository,
16.6s of a 17.6s install on Linux and 40.1s of 42.4s on Windows.
The verdict depends on the lockfile content and the policies, never on the
runner, so it is cached under its own key alongside the store cache and
restored without prefix fallback: an entry recorded for a different lockfile
could never be reused. Saving happens before `pnpm store prune`, which drops
the log along with the store's other derived state.
Anything that goes wrong here only costs the next job the re-verification, so
failures are reported as warnings instead of failing the build. Older pnpm
versions never write the log, and the post step then finds nothing to save.
* docs(README): point users to the successor pnpm/setup action
The pnpm setup action has moved to `pnpm/setup`, which installs
pnpm v11+ as a self-contained native executable and can install a
JavaScript runtime (Node.js, Bun, or Deno) in the same step,
replacing `actions/setup-node`.
Add a notice at the top of the README, a migration section with a
before/after workflow example and an input/output mapping table,
and mention the successor in the Notes section. The rest of the
docs stay intact since `pnpm/action-setup` remains the way to
install pnpm v10 and older.
Signed-off-by: Kevin Cui <bh@bugs.cc>
* docs(README): address review feedback on migration section
Add an explicit version: 11 to the migration example and note when the
input can be omitted, since pnpm/setup requires pnpm v11+ and a repo
migrating from version: 10 may have no packageManager field or one that
pins v10.
Move the v2 upgrade warning below the page title so the two callouts
are no longer adjacent blockquotes (markdownlint MD028), keeping the
successor notice and the legacy warning as separate blocks.
Fix the comma splice and use "set up" as the verb in the Notes
section.
Signed-off-by: Kevin Cui <bh@bugs.cc>
---------
Signed-off-by: Kevin Cui <bh@bugs.cc>
* add pnpm store caching
* style: format
* no semicolons
* no star imports
* import order
* style: no star imports
---------
Co-authored-by: khai96_ <hvksmr1996@gmail.com>
* feat: add an option to install the self-contained binary version of pnpm
* test: add a test about nodejs_bundled
* style: remove an empty line
* chore: use newer pnpm
* chore: update dependencies
* feat: rename `nodejs_bundled` to `standalone`
as @zkochan suggested
* docs: add
---------
Co-authored-by: Takashi Sato <takashi@tks.st>
Zoltan Kochan