2.4.0 — Renovate preset, validator gate, daily cadence
This release introduces the estate-wide Renovate preset as a public
catalog surface, alongside the per-tag rebuild of ci-* images and
the component versions that have always shipped on tag.
What consumers gain
-------------------
A central preset published from this repo. Every consumer renovate.json
can shrink to a single line:
{ "extends": ["gitlab>dunn.dev/pipeline:renovate-config"] }
The preset carries: platformAutomerge: true (GitLab merges minor+patch
on green CI without waiting for the next Renovate run), prHourlyLimit: 0
(no per-hour cap; daily run drains the queue), assignees set to the
maintainer accounts (so manual-review MRs land in the inbox), the
minor+patch automerge + major manual-review packageRules, and the
shared Containerfile ARG customManager used by every Pattern A
repackaging consumer (caddy-estate, pipeline's own ci-* images,
future auth upstream-software containers).
No `schedule` field in the preset. Cadence is owned by the runner's
CI cron schedule alone, with RENOVATE_FORCE overriding any stale
per-repo schedule at scan time.
Operational changes in this repo
--------------------------------
- New `validate-renovate` job runs `renovate-config-validator --strict`
on every MR touching renovate.json or renovate-config.json. A
malformed preset cannot reach consumers.
- Renovate runner job drops $CI_PIPELINE_SOURCE == "web". Entry
points are `schedule` (daily cron) and `api` only.
- Pipeline's own renovate.json now extends the preset and keeps only
the two catalog-specific managers: UBI date-stamped-tag filter
and the templates/*.yml Docker pin regex.
- README gains an Architecture section with the end-to-end Mermaid
diagram of the single-maintainer estate.
Container images
----------------
ci, ci-go, ci-rust, ci-runtime-go, ci-runtime-node all published at
:2.4.0 alongside this tag, matching every consumer's @2.4.0 pin
under the v2.0.0 triple-coupling contract.
Migration
---------
No breaking changes for existing consumers. Per-repo renovate.json
files continue to work; migration to the central preset is hygiene
and can be done one repo at a time. The fan-out lands as a sequence
of small per-repo MRs starting with dunn.dev/reference.