Now that verify is a required check, allow automerge for GitHub Action digest re-pins only

[wormeyman]

.github/renovate.json5 sets automerge: false globally, and that default should stay. But it was written before CI or branch protection existed, and the reasoning for one narrow category has changed now that both do.

What changed

• ci: the repo's first .github/ - a verify workflow plus Renovate with the holds encoded #56 added the verify workflow, so every PR gets a real check.
• Branch protection (ruleset EJ, 2026-07-30) makes verify a required status check on main with no bypass actors.

Renovate's automerge waits for a PR's checks to be green, and with a required check that cannot be bypassed, an automerged PR is structurally unable to land red. That was not true a day ago, and it was the stated reason automerge stayed off entirely.

The candidate, and only this one

GitHub Action digest re-pins. The config extends helpers:pinGitHubActionDigests, so Actions are pinned to a full SHA with a trailing # vX.Y.Z comment, and Renovate updates the SHA and the comment together. Renovate has already queued exactly this: chore(deps): update pnpm/action-setup digest to 0ebf471 (see the Dependency Dashboard).

These are worth automating because the change is mechanical, there is nothing to read in the diff beyond "the SHA moved", and the churn is recurring - it will arrive every few weeks forever. Reviewing them by hand teaches nobody anything and trains the habit of skimming bot PRs, which is worse than automating the boring case.

Rough shape:

{
  matchManagers: ["github-actions"],
  matchUpdateTypes: ["digest", "pin", "pinDigest"],
  automerge: true,
  automergeType: "pr",
  platformAutomerge: true,
}

platformAutomerge hands the merge to GitHub's own auto-merge, so the required check gates it rather than Renovate polling.

What must NOT be automerged, and why the global default stays

Everything else. The load-bearing reason is that pnpm run verify proves the repo is consistent, not that a bump is correct - and this repo has the exact counterexample on record. pako 3.0.0 flipped legacyHash to false; adopting it passes a green suite while silently breaking the codec's byte-exactness, and the resulting wrong belief ("pako cannot match zlib") survived roughly a year. test/deflate.spec.ts now guards that specific option, but the general lesson holds: a green gate is not a correctness proof for a dependency change.

Explicitly out of scope for automerge, permanently:

• anything in the codec path (pako above all)
• vite-plus (pre-1.0; its tsgolint bumps have twice re-triggered the TS2321 pathology in vite.config.ts)
• vue, pinia, vue-tsc
• wrangler / @cloudflare/vitest-pool-workers (grouped, and require a wrangler types regen afterwards)
• .node-version - it is what CI installs, and its prBodyNotes asks for a local verify on the new version first
• the factoriotools/factorio Docker digest - it pins the render container to a game version, which is a fixture-provenance decision, not a dependency bump

Prerequisite, and a caveat

Do not enable this while strict_required_status_checks_policy is false and several PRs are open, or an automerged digest PR can land against a main it was not tested against. Sequence it after the ruleset issue is resolved.

Caveat worth stating plainly: this trades a small amount of safety for less noise. If the answer is "the noise is fine, I would rather read every bot PR", closing this as declined is a perfectly good outcome - it is a preference, not a defect.