Repository navigation
Conversation
pnpm re-verifies every lockfile entry against minimumReleaseAge, the trust policy and tarball URLs on each install, which takes 22-40 s per job. It skips that check when lockfile-verified.jsonl in its cache directory records a passing result for the same lockfile content and policy, but setup-node only caches the store, so CI never kept that file. Cache the file per pnpm version and lockfile hash in the ci.yml install jobs and in format, query-counts, env-types, visual and preview-releases. The cache directory is pinned to pnpm's default so the cached path and pnpm's path always agree. release.yml, whose publish job has id-token: write, keeps the full check on every run.
|
github-actions
Bot
added
review/needs-review
🚀 Deploying Preview to Cloudflare 🚀Preview URL: https://daniel-ci-pnpm-verdict-cache.try.emdashcms.com, https://daniel-ci-pnpm-verdict-cache-emdash-playground.emdash-cms.workers.dev (commit 8bc9f82)This URL reflects your latest Preview deploymentPreview Deployments by commit
|
![emdashbot[bot]](https://avatars.githubusercontent.com/in/3255304?s=60&v=4){kind=small}
There was a problem hiding this comment.
The approach is sound: it caches only pnpm's lockfile-verified.jsonl record rather than disabling supply-chain checks, and it leaves the privileged workflows (Release, Auto Extract, Lunaria, release-action) unchanged. Both reviewers approved and found no correctness or security problems. A stale or bad cache entry can only cost a full check, since pnpm keys its lookup on the lockfile content hash and only reuses a pass made under the same or a stricter policy. The cache is also scoped away from untrusted runs. Both reviews were static, and neither confirmed pnpm's pnpm_config_cache_dir handling or the reported timings by running anything. One non-blocking suggestion remains: the cache key should also cover pnpm-workspace.yaml, which holds the policy. A verdict of comment rather than approve is used only so that suggestion is not lost. Only one reviewer raised it, and the other did not mention it.
Reviewed by anthropic/claude-opus-5-5 and openai/gpt-6.1-sol.
@emdash-cms/admin
@emdash-cms/auth
@emdash-cms/auth-atproto
@emdash-cms/blocks
@emdash-cms/cloudflare
@emdash-cms/contentful-to-portable-text
emdash
create-emdash
@emdash-cms/gutenberg-to-portable-text
@emdash-cms/plugin-cli
@emdash-cms/plugin-test
@emdash-cms/plugin-types
@emdash-cms/registry-client
@emdash-cms/registry-lexicons
@emdash-cms/registry-loader
@emdash-cms/registry-moderation
@emdash-cms/registry-verification
upgrade-emdash
@emdash-cms/sandbox-workerd
@emdash-cms/x402
@emdash-cms/plugin-ai-moderation
@emdash-cms/plugin-ai-search
@emdash-cms/plugin-atproto
@emdash-cms/plugin-audit-log
@emdash-cms/plugin-color
@emdash-cms/plugin-embeds
@emdash-cms/plugin-field-kit
@emdash-cms/plugin-forms
@emdash-cms/plugin-webhook-notifier
commit: |
pnpm only reuses a stored pass made under the same policy, and the policy lives in pnpm-workspace.yaml. With only the lockfile in the key, a policy change that leaves the lockfile alone still hits the old cache entry: pnpm rejects the pass and runs the full check, but actions/cache does not save on an exact key hit, so every later job repeats the full check until the lockfile changes.
emdashbot
Bot
added
review/needs-review
There was a problem hiding this comment.
The follow-up is the right, narrowly scoped change: including the policy file in the cache key preserves reuse after policy edits without changing pnpm's checks.
Verified all 14 cache keys across the six affected workflows now hash both pnpm-lock.yaml and pnpm-workspace.yaml. This addresses the earlier suggestion and matches the author's reply. No findings remain, and I found no new defects in the follow-up diff.
Review was static; workflows and reported timings were not independently executed or verified.
Follow-up review by openai/gpt-6.1-sol, scoped to the changes since the last review.
github-actions
Bot
removed
the
ci:run
What does this PR do?
Makes
pnpm installabout 15 seconds faster in most CI jobs by keeping pnpm's record of a passed lockfile check. On every install, pnpm 11 checks the 1,997 lockfile entries againstminimumReleaseAge, the trust policy and the tarball URLs, which takes about 35 seconds and runs partly alongside the rest of the install. It skips that check whenlockfile-verified.jsonlin its cache directory records a pass for the same lockfile content, butsetup-nodeonly caches the store, so CI jobs never had that file.A new step keeps the file in
actions/cache, keyed on the pnpm version and the hashes ofpnpm-lock.yamlandpnpm-workspace.yaml, where the policy lives. It also sets pnpm's cache directory to its default (~/.cache/pnpm) so the cached path and pnpm's path can't drift apart. A changed lockfile or policy finds no cached record, so it gets the full check, and its new pass is saved for the jobs that start later. pnpm checks this on its own too: it only reuses a pass made for the same lockfile content under the same or a stricter policy. The step runs in the nine install jobs inci.ymland in Format, Query Counts, Env Types, Visual Regression and Preview Releases. Release, Auto Extract and Lunaria, which run with write access, and the Dependabot-only release-action bundle job keep the full check on every run.Type of change
Your connection to this change
Checklist
pnpm typecheckpassespnpm lintpassespnpm testpasses (or targeted tests for my change)pnpm formathas been runmessages.pochanges except in translation PRs — a workflow extracts catalogs on merge tomain. (n/a: no admin UI change)AI assistance disclosure
Screenshots / test output
Test output:
mainruns up to 8da0792 (2026-10-20),pnpm installtook a median 38 s over all jobs, and pnpm's log put the lockfile check at a median 35 s (22 to 40 s).pnpm installtook a median 21 s (18 to 25 s), against 37 s (28 to 42 s) in a second run ofmainthere (run)..github/zizmor.yml: no findings in the default persona, and the same counts asmainin the pedantic and auditor personas.