chore(renovate): add opt-in automerge preset, group toolchain, batch weekly #81

Sammanfogat

supernaut sammanfogade 1 incheckning från chore/renovate-automerge-preset in i main

2026-08-09 19:54:59 +00:00

supernaut kommenterad

2026-08-09 19:34:47 +00:00

Ägare

Volume

toolchain group now spans both datasources. The old toolchain (volta) rule matched
node and pnpm, but every service repo pins Node twice — once in package.json volta
and once as the Containerfile base image (docker.io/library/node), which is a different
depName from a different datasource. So the group caught the Volta pin and let the container
pin open its own PR. Beyond the extra PR, that meant nothing kept the two Node pins in step
and they could silently drift to different versions. Renamed to toolchain because "volta"
is no longer accurate.
Non-security updates batch weekly (schedule: before 6am on monday), matching the
existing lockFileMaintenance window, instead of trickling in daily.
prConcurrentLimit / prHourlyLimit stated explicitly rather than relying on Renovate's
defaults of 10/2.

The security path is untouched: vulnerabilityAlerts already overrides both schedule and
minimumReleaseAge, so vulnerability fixes still land immediately.

Automerge

New named preset automerge-safe.json, referenced as
local>bitborg/bitborg-docs:automerge-safe. It automerges non-major devDependencies, the
toolchain group, and the weekly lockfile PR — via automergeType: pr + platformAutomerge,
so Forgejo does the merging once the required ci check passes.

It is opt-in, and deliberately so. Extending it is an assertion that a merge to that repo's
default branch ships nothing to production. Two repos are excluded, with the reasoning recorded
in their own renovate.json so it does not have to be re-derived later:

bitborg-web — a merge to main is a deploy. deploy.yml fires on push to main,
builds the image, and the services host pulls it via podman auto-update (ADR 0019) with no
operator present. CI is a strong gate and a failed healthcheck rolls the container back, but
neither proves a bumped dependency left the served portal behaving the same.
bitborg-infra — counterintuitively, because merging triggers nothing. The
customManagers bump *_image_tag values in group_vars, i.e. declared production state
that reaches prod on the next Ansible apply — quite possibly run for an unrelated reason by
someone who never reviewed the bump. Compounded by #63, where a tag bump can no-op without a
pull+restart, so the running version does not reveal what happened either.

Opting in from each repo's side, rather than listing repositories here with
matchRepositories, keeps the policy defined exactly once while keeping this public file free
of any repository inventory. It also fails safe: a newly onboarded repo does not automerge until
someone has actually reasoned about its deploy path.

The toolchain automerge rule matches by depName, mirroring the group, not by
matchDepTypes: [volta, packageManager]. The group spans two managers so its members carry
different depTypes, and a depType-only rule would mark part of a single grouped branch
automergeable while leaving the container pin out — forcing Renovate to derive one branch config
from conflicting automerge values. The two depName lists are cross-referenced in both files.

Majors are unaffected throughout: still held by major.dependencyDashboardApproval, and
excluded from every automerge rule, since ticking that box means "open the PR for me to look at",
not "ship it unreviewed".

Verification

renovate-config-validator passes on all three files, plus the six consuming renovate.json
files on their own branches. Prettier clean. Branch protection was confirmed to require the ci
status check in every repo — that is the load-bearing precondition, since automerge merges on
Renovate's view of checks.

Not provable locally: that platform automerge works on Forgejo 16.0.1 (Renovate falls back to
merging itself if it does not, so the effect holds either way), and that the group captures
docker.io/library/node at runtime — though branch renovate/docker.io-library-node-24.x
confirms that depName. The real proof is the next Monday run.

Merge order

This must merge before the six repos that reference the new preset, otherwise
local>bitborg/bitborg-docs:automerge-safe will not resolve for them.

Afterwards the seven open renovate/toolchain-(volta) PRs become orphaned by the group rename
and can be closed; new renovate/toolchain branches supersede them.

Follow-ups this makes more pressing

Both already filed and both now matter more, since less human attention flows through these PRs:
the missing github.com PAT (#12) means automerged PRs carry no changelog anyone could have read,
and the absent Renovate staleness alert means a bot that has stopped entirely is invisible —
and less likely to be noticed by the absence of PRs, since nobody is watching for them.

Renovate was opening ~18 PRs at a time across the estate, and almost all of it was fan-out rather than genuinely new work: every repo pins an identical Node/pnpm toolchain, so one upstream pnpm release produced one near-identical PR per repo. ## Volume - **`toolchain` group now spans both datasources.** The old `toolchain (volta)` rule matched `node` and `pnpm`, but every service repo pins Node *twice* — once in `package.json` `volta` and once as the Containerfile base image (`docker.io/library/node`), which is a different depName from a different datasource. So the group caught the Volta pin and let the container pin open its own PR. Beyond the extra PR, that meant nothing kept the two Node pins in step and they could silently drift to different versions. Renamed to `toolchain` because "volta" is no longer accurate. - **Non-security updates batch weekly** (`schedule: before 6am on monday`), matching the existing `lockFileMaintenance` window, instead of trickling in daily. - **`prConcurrentLimit` / `prHourlyLimit` stated explicitly** rather than relying on Renovate's defaults of 10/2. The security path is untouched: `vulnerabilityAlerts` already overrides both `schedule` and `minimumReleaseAge`, so vulnerability fixes still land immediately. ## Automerge New named preset `automerge-safe.json`, referenced as `local>bitborg/bitborg-docs:automerge-safe`. It automerges non-major devDependencies, the toolchain group, and the weekly lockfile PR — via `automergeType: pr` + `platformAutomerge`, so Forgejo does the merging once the required `ci` check passes. It is **opt-in**, and deliberately so. Extending it is an assertion that a merge to that repo's default branch ships nothing to production. Two repos are excluded, with the reasoning recorded in their own `renovate.json` so it does not have to be re-derived later: - **`bitborg-web`** — a merge to `main` *is* a deploy. `deploy.yml` fires on push to `main`, builds the image, and the services host pulls it via `podman auto-update` (ADR 0019) with no operator present. CI is a strong gate and a failed healthcheck rolls the container back, but neither proves a bumped dependency left the served portal behaving the same. - **`bitborg-infra`** — counterintuitively, *because* merging triggers nothing. The `customManagers` bump `*_image_tag` values in `group_vars`, i.e. declared production state that reaches prod on the next Ansible apply — quite possibly run for an unrelated reason by someone who never reviewed the bump. Compounded by #63, where a tag bump can no-op without a pull+restart, so the running version does not reveal what happened either. Opting in from each repo's side, rather than listing repositories here with `matchRepositories`, keeps the policy defined exactly once while keeping this public file free of any repository inventory. It also fails safe: a newly onboarded repo does not automerge until someone has actually reasoned about its deploy path. The toolchain automerge rule matches by **depName**, mirroring the group, not by `matchDepTypes: [volta, packageManager]`. The group spans two managers so its members carry different depTypes, and a depType-only rule would mark part of a single grouped branch automergeable while leaving the container pin out — forcing Renovate to derive one branch config from conflicting `automerge` values. The two depName lists are cross-referenced in both files. Majors are unaffected throughout: still held by `major.dependencyDashboardApproval`, and excluded from every automerge rule, since ticking that box means "open the PR for me to look at", not "ship it unreviewed". ## Verification `renovate-config-validator` passes on all three files, plus the six consuming `renovate.json` files on their own branches. Prettier clean. Branch protection was confirmed to require the `ci` status check in every repo — that is the load-bearing precondition, since `automerge` merges on Renovate's view of checks. Not provable locally: that platform automerge works on Forgejo 16.0.1 (Renovate falls back to merging itself if it does not, so the effect holds either way), and that the group captures `docker.io/library/node` at runtime — though branch `renovate/docker.io-library-node-24.x` confirms that depName. The real proof is the next Monday run. ## Merge order This must merge before the six repos that reference the new preset, otherwise `local>bitborg/bitborg-docs:automerge-safe` will not resolve for them. Afterwards the seven open `renovate/toolchain-(volta)` PRs become orphaned by the group rename and can be closed; new `renovate/toolchain` branches supersede them. ## Follow-ups this makes more pressing Both already filed and both now matter more, since less human attention flows through these PRs: the missing github.com PAT (#12) means automerged PRs carry no changelog anyone could have read, and the absent Renovate staleness alert means a bot that has stopped entirely is invisible — and less likely to be noticed by the absence of PRs, since nobody is watching for them.

supernaut lade till 1 incheckning

2026-08-09 19:34:47 +00:00