feat(renovate): bring renovation online across the group
What this closes
!83 (merged) restored MR creation for the 20 projects that carry a renovate.json. This closes the rest of the gap and makes the arrangement durable.
Inherited enrollment — the big one
The runner now injects this catalog's own preset as base config for every autodiscovered project:
RENOVATE_REQUIRE_CONFIG: "optional"
RENOVATE_CONFIG: '{"extends":["gitlab>gitlab-com/public-sector/pipeline:renovate-config"]}'Under the previous required model, 37 of 57 projects had no renovate.json and were therefore silently unmanaged. The failure mode is that absence reads as "unmanaged" rather than "not yet enrolled", and nothing anywhere surfaces the difference — the runner reports a clean scan either way.
A project now opts out explicitly with {"enabled": false}. A project needing overrides still ships its own renovate.json, which merges on top of the injected base. Enrollment becomes opt-out instead of opt-in, which is the only version of this that stays complete as the group grows.
RENOVATE_FORCE — the architectural fix behind !83 (merged)
!83 (merged) widened the preset's schedule window to stop it closing before the runner executes. That fixed the instance. This fixes the class:
RENOVATE_FORCE: '{"schedule":null,"automergeSchedule":null,"prHourlyLimit":0}'A Renovate config schedule and a CI cron are two independent time gates, and when they disagree the bot goes quiet without failing. Nulling the inherited schedule makes the cron the single source of cadence, so a project that copies a stale renovate.json in from outside the estate gets normalized at the runner level instead of silently parking its updates.
prConcurrentLimit is deliberately not overridden. That stays the useful throttle — a per-repo ceiling on open MRs. prHourlyLimit is the one that interacts badly with an infrequent cron: at 4/hour on a weekly run, a project drains four updates per week, which is what capped the backlog even with the window open.
Everything else in here
| Change | Why |
|---|---|
Autodiscovery skips *-deletion_scheduled-* |
Purge-pending projects linger through the retention window, autodiscovery still finds them, and the dashboard write fails — a guaranteed warning every scan for a project that is already gone |
needs: [] on renovate |
The job is in the last stage, so an earlier-stage failure skipped it. On this catalog the likely failure is a container build on a rotated base-image digest — precisely what Renovate would have bumped. That is a deadlock. Load-bearing for web-triggered runs, which execute the full pipeline |
timeout: 1h 30m, retry broadened to 3 infra classes |
Stops a growing autodiscover scan being killed mid-run into a partial green, without retrying a real Renovate error into a different failure |
validate:renovate-config job |
Every project resolves the shared preset at scan time, so a schema error here is a group-wide outage. Pinned to the Renovate major the runner executes — an unpinned npx renovate-config-validator resolves an older major and reports false errors on current keys like managerFilePatterns |
ci-tools glab datasource |
Declared datasource=github-releases for gitlab-org/cli, a GitLab-hosted project. Returned no-result silently every scan; the pin sat at v1.92.1 while v1.108.0 shipped |
ADOPTION.md |
So "deliberately exempt" and "nobody got round to it" stop being indistinguishable |
What is deliberately NOT in here
The review-gated posture is untouched. platformAutomerge stays false, every packageRule keeps automerge: false, and automerge-gate's customer_shipping floor is unchanged. Enrolling more projects raises review volume; it does not relax any merge decision. This estate ships to customers in regulated environments and dependency traffic stays a human call.
Gate fan-out. osv-verdict + automerge-gate coverage across consumer projects is a separate, per-project exercise — and one that needs an osv-scanner scan source -r pre-check per project first, because automerge-gate also runs fail-closed on the default branch. A project with pre-existing findings passes its MR via diff-mode and then goes red on main after merge. That trap deserves its own change, not a footnote in this one.
Expected effect
The next scan enrolls 37 additional projects and lifts the hourly cap, so expect a large single batch of MRs, bounded per project by prConcurrentLimit: 10. minimumReleaseAge: 7 days and internalChecksFilter: strict still hold anything freshly published, so the batch is aged updates only.
Recommended follow-through after merge, in order:
- Move the pipeline schedule from weekly (
0 6 * * 1) to daily (0 6 * * *). With the hourly cap lifted, a weekly cron delivers the whole group's traffic in one burst; daily smooths it. The preset header now recommends daily. - Trigger one run immediately rather than waiting for the cron, to get the drain started and confirm the enrollment behaves.
Validation
glab ci lint— valid.- Both embedded JSON payloads (
RENOVATE_FORCE,RENOVATE_CONFIG) parse. - Both changed YAML files parse.
- The MR pipeline runs
renovate-dry-runinlookupmode against this project, which is the cheap end-to-end check that the runner config still resolves.
The one thing no pre-merge check can prove is the enrollment behaviour on the 37 previously-unmanaged projects — that is only observable on the first real scan. It is a variable flip with a documented opt-out, and reverting is a one-line change.