Renovate: auto-merge non-major npm updates once CI is green (#56) #82
No reviewers
Labels
No labels
area/ai
area/backend
area/frontend
area/infra
area/scheduler
area/wled
good-first-issue
priority/high
priority/low
priority/medium
type/bug
type/chore
type/ci-cd
type/docs
type/feature
type/qa
v1.0.0
v1.1.0
v1.2.0
v2.0.0
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
rbrooks/Iris-WLED!82
Loading…
Reference in a new issue
No description provided.
Delete branch "chore/renovate-automerge-npm"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Third checkbox on #56, and the first change to land through the new branch protection.
renovate.jsonalready auto-mergedgithub-actionsminor/patch/digest bumps. This extends the same treatment to the batchednpm (non-major)group.Why this is safe: Renovate's automerge waits for a green branch, so it cannot land anything CI rejects. The eslint bump that broke lint earlier today would have sat red and unmerged rather than auto-merging itself in. Majors are untouched — they stay behind
major.dependencyDashboardApprovaland get merged by hand.Why it pairs with protection: gating merges on green checks is precisely what makes unattended merging of routine dependency churn safe. Six weeks of drift produced 5 stale PRs and 6 advisories; this stops the queue rotting again.
This PR doubles as the end-to-end test of the protection rule enabled for #56:
mainare blocked — verified,Forgejo: Not allowed to push to protected branch mainstatus_check_contexts: ["CI / *"](the pattern the sibling repos on this instance use), so theCIworkflow's jobs must passDependency auditworkflow is deliberately not matched by that glob, so advisories report without gating mergesrequired_approvals: 0, since requiring one on a single-maintainer repo would deadlock on self-approvalCorrection — added a 3-day release quarantine (
08e3114)A security review flagged this PR for enabling auto-merge without a release-age quarantine. It was right, and it exposes a flaw in the justification I gave above.
I argued the change was safe because "Renovate's automerge waits for a green branch, so it cannot land anything CI rejects." That is true, and it is the wrong threat model. Green CI is not a defence against supply-chain compromise — a hijacked package's
postinstalldoes not failruff,mypy,vitestor Playwright. It simply runs.The exposure here is concrete rather than theoretical:
npm ciexecutes in thefrontendanddocker-e2ejobs on the shared runnerrelease.ymlruns withsecrets.GITHUB_TOKEN, which holds registry push credentialsSo a compromised minor/patch publish could have been picked up within hours, passed every check, and merged to
mainunattended.Change
minimumReleaseAge: "3 days"on both automerge rules — npm and github-actions. The actions rule had the same unguarded automerge, and actions execute directly in the runner, so guarding only npm would have half-closed the hole.Verified no automerge rule is left unguarded:
radix-uiandeslintset onlygroupName, so they inherit bothautomergeand the quarantine from the npm rule for minor/patch. A radix major matches only the radix rule (which has nomatchUpdateTypes), never the non-major rule, so majors stay dashboard-gated and hand-merged.Malicious npm publishes are typically caught and yanked within hours to a couple of days, so the quarantine removes the window where we would be the early adopter. The cost is patches landing three days later.
claude-bot referenced this pull request2026-08-31 05:45:41 +00:00