Found while implementing #5306 (root engines corrected to node: ">=22.11" / pnpm: ">=10"). Out of that card's scope — its sweep covers prose restating the supported range, and this is a copy-paste recipe that drifted from the workflows it claims to mirror — so filing rather than riding along.
content/docs/guide/ci-cd-pipeline.md:1626-1637 tells a contributor adding a workflow to "Follow the existing pattern for pnpm + Turbo setup" and gives:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
- uses: actions/setup-node@v4with:
node-version: 20cache: 'pnpm'
- run: pnpm install --frozen-lockfile
Measured against .github/workflows/ on 090927f4f:
| The snippet says | The workflows actually do |
|---|
actions/setup-node@v4 | actions/setup-node@v7 — 27 occurrences, no other version |
node-version: 20 | node-version: '22.x' in every workflow (one spells it '22') — and 20 is now below the declared engines.node floor of 22.11 |
pnpm/action-setup@v4 | zero occurrences anywhere in the repo — pnpm comes from run: corepack enable plus root packageManager: pnpm@10.31.0 |
So every claim in the "existing pattern" is wrong, and the one a contributor is most likely to keep — the Node version — now contradicts the manifest as well. The same page states the truth 1,400 lines earlier (Uses: Node 22.x, pnpm via corepack, line 196, which is inventoried in the doc-version-claims ledger), so the page disagrees with itself.
Why nothing caught it: the snippet sits in a fenced block, and scripts/__tests__/doc-version-claims.test.ts skips fences by design; ci-cd-pipeline-doc.test.ts checks that every workflow file has a heading on this page, not that the page's examples match the workflows.
Fix is mechanical — rewrite the snippet from any current workflow's setup steps. Worth deciding at the same time whether the snippet should exist at all or point at a named workflow as the living example, since a copied YAML block is a fossil by construction.
Neighbouring, not the same: #6280 covers two stale coverage claims about check-doc-links' scan surface on this page.
Generated by Claude Code
Found while implementing #5306 (root
enginescorrected tonode: ">=22.11"/pnpm: ">=10"). Out of that card's scope — its sweep covers prose restating the supported range, and this is a copy-paste recipe that drifted from the workflows it claims to mirror — so filing rather than riding along.content/docs/guide/ci-cd-pipeline.md:1626-1637tells a contributor adding a workflow to "Follow the existing pattern for pnpm + Turbo setup" and gives:Measured against
.github/workflows/on090927f4f:actions/setup-node@v4actions/setup-node@v7— 27 occurrences, no other versionnode-version: 20node-version: '22.x'in every workflow (one spells it'22') — and 20 is now below the declaredengines.nodefloor of 22.11pnpm/action-setup@v4run: corepack enableplus rootpackageManager: pnpm@10.31.0So every claim in the "existing pattern" is wrong, and the one a contributor is most likely to keep — the Node version — now contradicts the manifest as well. The same page states the truth 1,400 lines earlier (
Uses: Node 22.x, pnpm via corepack, line 196, which is inventoried in thedoc-version-claimsledger), so the page disagrees with itself.Why nothing caught it: the snippet sits in a fenced block, and
scripts/__tests__/doc-version-claims.test.tsskips fences by design;ci-cd-pipeline-doc.test.tschecks that every workflow file has a heading on this page, not that the page's examples match the workflows.Fix is mechanical — rewrite the snippet from any current workflow's setup steps. Worth deciding at the same time whether the snippet should exist at all or point at a named workflow as the living example, since a copied YAML block is a fossil by construction.
Neighbouring, not the same: #6280 covers two stale coverage claims about
check-doc-links' scan surface on this page.Generated by Claude Code