fix(renovate): widen schedule window so scheduled runs open MRs

What

Public Sector Renovate has effectively stopped opening merge requests. MRs created across the group fell from 22 in May → 12 in June → 2 in July. Only 4 are open, and all 4 are green, conflict-free and zero-approvals-required — they were waiting on a click, not on CI.

The runner is not the problem. The 2026-07-20 run autodiscovered 56 repos, finished green in ~12 minutes, and refreshed every dashboard.

Root cause: the preset schedules updates outside the window its own runner executes in

schedule: ["before 6am on Monday"] means Monday 00:00–05:59 UTC. The pipeline schedule's cron fires at 06:00 UTC and the renovate job actually starts 06:07–06:09. Every run lands after the window closes.

Renovate's updateNotScheduled default is true, so existing branches still get refreshed out-of-window — which is exactly what the last run shows (one PR updated on ironbank, zero branches created). New branches are never created. So the bot looks healthy while producing nothing.

Everything parks in Awaiting Schedule instead, indefinitely:

Project	Awaiting Schedule	Pending Status Checks
pipeline	12	4
tach	11	5
reference	24	—

Widening to before 9am on Monday leaves roughly three hours of slack for queue delay and the job's own runtime.

Also in this MR

Both are the other two items from #2 (closed), now that the trace confirmed what they actually are:

UBI10 grouping. The group rule matched registry.access.redhat.com/ubi9{/,}** only, so ubi10 consumers got ungrouped erratum bumps. Now ubi{9,10}{/,}**.

The gitlab-tags lookup-failure warning. Eight consumer dashboards carry Failed to look up gitlab-tags package gitlab-com/public-sector/pipeline: no-result. This is not the bot access problem #2 (closed) assumed — the project is public and its tags API returns 200 unauthenticated. It is Renovate's native gitlabci manager reading component: $CI_SERVER_FQDN/gitlab-com/public-sector/pipeline/<name>@vX.Y.Z and treating the unresolved CI variable as the registry host.

Critically, the component pins were never unmanaged. The customManagers regex entry tracks them correctly with a hardcoded packageName and the gitlab-releases datasource — tach's dashboard is currently offering container → v4.1.0, audit → v3.3.2 and so on. So the native extraction was pure duplicate noise, and it is now disabled for this one package. #2 (closed)'s item 2 was accurate when filed (the depName then pointed at the dead public-sector-tools namespace) and has since been fixed in substance by the customManager.

Closes #2 (closed).

Validation

renovate-config-validator --strict against renovate 43.272.0 — the exact version the runner executes — passes as a repo config. Note that an unpinned npx renovate-config-validator resolves to 37.x, which predates managerFilePatterns and reports four false errors on this file; pin the version when validating this preset.

Draining after this merges

The window fix alone does not drain the backlog quickly: prHourlyLimit: 4 plus a weekly cron caps creation at roughly 4 MRs per week. Rather than change those limits in the preset and need a revert MR, run the renovate job once manually with RENOVATE_PR_HOURLY_LIMIT=0 and RENOVATE_PR_CONCURRENT_LIMIT=0 as job variables. Env config overrides the preset, the lift applies to that run only, and nothing needs reverting.

Expect a large single batch of MRs across the 20 configured projects. minimumReleaseAge: 7 days and internalChecksFilter: strict still hold anything too fresh, so the batch is aged updates only.

Follow-ups, not in this MR

• egress (created 2026-07-21, one day after the last run, so never yet visited) has a renovate.json using regexManagers and fileMatch — both removed in Renovate 41 — plus the deprecated //presets/renovate.json shim path. It will hard-error on its first run.
• Inherited-config model. 37 of 57 projects have no renovate.json and are therefore unmanaged. Setting RENOVATE_CONFIG + RENOVATE_REQUIRE_CONFIG: optional on the runner would enroll every autodiscovered repo with no per-repo file, opting out via {"enabled": false}. This is a deliberate scope decision, not a bug fix, so it is left out here.
• Five projects have duplicate open Dependency Dashboard issues, the stale copies still naming the dead public-sector-tools namespace: assay, kaniko, storyping, tach, tach-classifier.
• Four site/package.json trees tripped Dependency has update(s) proposed which would update you to a malicious version - skipping: manifold, postern, reference, serviceping-redact. Renovate refused the update, so there is no exposure, but the package is worth identifying.

🤖 Generated with Claude Code