Reverse Renovate's grouping policy — per-dep PRs, not grouped #127
Labels
No labels
area:auth
area:ci
area:db
area:infra
area:native
area:pwa
area:service
epic
feature
foundation
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
james/carol#127
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Reverses the "Grouped PRs" decision from ADR-0009 §3. The grouping was originally chosen to keep the typical week's PR volume to a handful, but in practice the upgrades inside a single grouped PR want to be tested and merged independently: a patch to one prod dep doesn't share a test surface with a patch to another, and bundling them just means a green CI run on the bundle while no individual upgrade is being judged on its own merits.
Going forward, each dep upgrade gets its own PR. Auto-merge stays in effect for the lockfile-only patch/minor cases (per-PR CI gates them individually); majors / actions / Dockerfile base-image bumps still require human review, also per-PR.
Scope
groupNamefromrenovate.json'spackageRules.docs/ci.md"Dependency updates (Renovate)" → "Policy" section: drop the "Grouped PRs" enumeration; replace with a "Per-dep PRs" note explaining each dep upgrade is its own PR.automerge: truestill attaches to the patch/minor lockfile-only paths — the user-facing change is "individual PRs" not "no more auto-merge".Acceptance criteria
renovate.jsoncontains nogroupNamefields.npx --yes --package=renovate@latest -- renovate-config-validatorpasses.docs/ci.md"Policy" section reflects the new per-dep shape.Out of scope
Changing quarantine, lockfile-only default, or the auto-merge boundary. Those decisions from ADR-0009 stay as-is.