ci(dependabot-auto-merge): drop the lockfile merge driver it cannot invoke

[os-warren]

Fixes#6369

.github/workflows/dependabot-auto-merge.yml configured the pnpm-lock.yaml merge driver, and had no occasion to invoke it. Both halves the pin requires ship here together.

The falsification attempt came first

The card's reading only stands if nothing in that job merges locally, so the sweep ran over the whole file before anything was deleted — with a control term on every zero-hit, since a zero-hit with no control is not a reading:

$ grep -inE '\bgit[[:space:]]+(merge|rebase|pull|cherry-pick|am|apply|revert|stash|checkout|reset|fetch|clone|push|commit|add)\b' .github/workflows/dependabot-auto-merge.yml
105: - name: Configure Git merge driver for pnpm-lock.yaml <- a step NAME, not an invocation
$ grep -inE '\bgit[[:space:]]+(config|merge|rebase)\b' .github/workflows/dependabot-auto-merge.yml # control
105: - name: Configure Git merge driver for pnpm-lock.yaml
109: git config merge.pnpm-merge.name "pnpm-lock.yaml merge driver"
110: git config merge.pnpm-merge.driver "pnpm install --no-frozen-lockfile"

The control proves the sweep reads: git config is matched by the same regex shape a git merge would be. Every literal git in the file is on lines 105–110, and the only two that execute are the git config pair being removed. rebase, cherry-pick and git apply are zero across the file.

Three things that could have merged without spelling it git, each checked rather than assumed:

• actions/checkout@v7 fetches a ref and checks it out. On a pull_request event that ref is the merge commit GitHub has already computed — checking out an existing commit performs no three-way merge, so no driver is consulted. (submodules: true also finds no .gitmodules in this repo.)
• scripts/dependabot-merge-gate.mjs, the job's only node step, imports node:fs and one local helper. No child_process, no exec, no spawn, no git — control term GATE_TIMEOUT_SECONDS hits in the same sweep.
• dependabot/fetch-metadata@v3 and actions/github-script@v9 read the API and post a comment; the inline script is visible in the file and only calls issues.createComment.

The one merge the job really does perform is the last step's gh pr merge --auto --squash, and GitHub executes that server-side in the merge queue. The runner's local git config is not consulted and cannot participate. So the driver was inert — the same no-occasion property #6358 measured on changelog.yml, reached by a different route: that job never merged at all, this one merges only where local config cannot reach.

⛔ Not claimed: that the configuration was harmful. It cost two lines and no runtime. The claim is only that it was inert, and that the repo was teaching otherwise.

What the table is down to

This is the reason the change is worth making. scripts/__tests__/ci-cd-pipeline-doc.test.ts pins the "Lockfile Merge Driver" table against the workflows that actually configure merge.pnpm-merge, in both directions — so it is documentation with a gate behind it. With changelog.yml removed by #6358 and this one removed here, that table has one row left: changeset-release.yml.

⚠️ One thing this PR deliberately does not assert, because I did not measure it: that the remaining row is itself live. The same sweep over changeset-release.yml finds no git merge, rebase or pull either — its commits and pushes go through changesets/action@v1, which force-pushes the version branch. Whether that reaches a driver is a separate question on a workflow this card does not cover, and I have left it entirely alone. It is called out in my report for triage rather than answered here.

Both halves, because they are pinned against each other

Reverse-verified rather than asserted. From the committed state, each half was restored alone and the pin re-run:

Ablation	Result	Failure message
doc row restored, workflow edited	red	the "Lockfile Merge Driver" table names workflows that do NOT configure merge.pnpm-merge
workflow step restored, doc edited	red	these workflows configure the pnpm-lock.yaml merge driver but have no row

Each mutation was confirmed on disk by a git hash-object change before the run, and each restoration proven by git diff HEAD reporting zero changed paths afterwards — not by a trap having fired.

Changed

• .github/workflows/dependabot-auto-merge.yml:105–110 — the step goes; a comment in its place records why, what was swept, and that restoring it needs a real local merge first.
• content/docs/guide/ci-cd-pipeline.md:1527 (the workflow's own section bullet), :1597–1602 (the pinned table row, and "Two workflows" → "One workflow").
• scripts/__tests__/dependabot-merge-gate.test.ts:543–545 — a third pin, not named in the card and red without this: the test named "keeps the lockfile merge driver ci-cd-pipeline.md pins it for" asserted the workflow still contained merge.pnpm-merge.driver. Its own title states its premise is the doc row, so it goes with the row. Test count moves 69 → 68 on those two files, which is exactly this one assertion.

Two citations my deletion would have silently falsified — both used this workflow's driver line as the repo's live worked example for "a quoted pnpm install that is not an install" — are re-pointed at changeset-release.yml:525–526, which still carries the identical line:

• scripts/check-pre-install-import-graph.mjs:275–278
• scripts/__tests__/check-pre-install-import-graph.test.ts:114–117 (comment only; the fixture beside it is a synthetic string and unaffected)
• content/docs/guide/ci-cd-pipeline.md:777–779, the same example in prose

Stopping the class from regenerating (#6369 disposition 3)

#6358 already corrected "merges or pushes" in this guide. Two residues of the same over-wide instruction remained, and both are sentence-level, in the section this PR is already editing:

1. "every workflow that merges, rebases, or commits onto a branch that may have moved" — the exact phrasing finding(ci): changelog.yml configures the pnpm-lock merge driver but never sets up node or corepack — both sibling workflows that configure the same driver do #6358 repudiated, still standing three paragraphs above the correction. Now: a local merge or rebase, one git carries out on the runner.
2. "Adding a workflow that merges?" would still have caught this workflow, which does merge — server-side. That is precisely how this dead copy got written, so the guide now names both readings that produced one: a push is not a merge, and a server-side merge is not a local one.

Verification

pnpm vitest run scripts/__tests__ on the committed tree 901c56704: 79 files, 2278 tests, all passed. The two named pins verbose: lists exactly the workflows that configure merge.pnpm-merge — in both directions ✓ and keeps the .gitattributes half of the mechanism true ✓ (.gitattributes is untouched — changeset-release.yml still needs it).

Gates touched by these edits, each read from its own verdict line: check-pre-install-import-graph OK (16 pre-install steps, 18 modules walked) · check-changeset-no-major OK · check-control-bytes OK (5262 files) · check-changeset-presence OK. Changeset is empty-frontmatter — no published package src/ is touched, so this declares "no release" explicitly.

Note, not asserted

With the driver gone, corepack enable and pnpm --version (:91–95) are the only pnpm-related steps left in a job whose own comment says it "never runs pnpm install" — the driver body was the only thing in it that needed pnpm. Removing them is a judgement I did not make here, and actions/setup-node must stay regardless (the gate script needs Node). Flagged for the reviewing seat rather than acted on.

---

Generated by Claude Code