chore(renovate): stop the hourly PR limit acting as a weekly one #97

Sammanfogat

supernaut sammanfogade 1 incheckning från chore/renovate-pr-limits in i main

2026-09-08 20:18:43 +00:00

supernaut kommenterad

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

Ägare

What

default.json: prHourlyLimit 2 to 0 (unlimited), prConcurrentLimit 3 to 6. Nothing else changes. The weekly schedule stays.

Why

The preset gives Renovate one run per week inside before 6am on monday. prHourlyLimit counts PRs created in the past hour, so with a single weekly run it caps every repo at two new PRs per week. prConcurrentLimit counts open PRs too, so while three PRs waited for review nothing new was created at all.

Result on 2026-09-08: 13 updates across the org had been held for 19 to 21 days and RenovateUpdateHeldTooLong was firing for 16 branches. bitborg-web alone had 7 held updates, which is four Mondays of drain at the old rate even with no new arrivals. The infra dashboard exporter showed them cycling between awaiting_schedule and rate_limited.

The hourly limit exists to stop notification floods on hourly runs. On a weekly window it is the wrong throttle. The concurrent limit is the right one and stays, raised so review capacity rather than the limit decides the queue.

Impact

One busy Monday while the backlog drains, then steady state. Repos that extend automerge-safe clear their own PRs. No Ansible apply needed: Renovate reads the preset from this repo on every run.

## What `default.json`: `prHourlyLimit` 2 to 0 (unlimited), `prConcurrentLimit` 3 to 6. Nothing else changes. The weekly schedule stays. ## Why The preset gives Renovate one run per week inside `before 6am on monday`. `prHourlyLimit` counts PRs created in the past hour, so with a single weekly run it caps every repo at two new PRs per week. `prConcurrentLimit` counts open PRs too, so while three PRs waited for review nothing new was created at all. Result on 2026-09-08: 13 updates across the org had been held for 19 to 21 days and `RenovateUpdateHeldTooLong` was firing for 16 branches. bitborg-web alone had 7 held updates, which is four Mondays of drain at the old rate even with no new arrivals. The infra dashboard exporter showed them cycling between `awaiting_schedule` and `rate_limited`. The hourly limit exists to stop notification floods on hourly runs. On a weekly window it is the wrong throttle. The concurrent limit is the right one and stays, raised so review capacity rather than the limit decides the queue. ## Impact One busy Monday while the backlog drains, then steady state. Repos that extend `automerge-safe` clear their own PRs. No Ansible apply needed: Renovate reads the preset from this repo on every run.

supernaut lade till 1 incheckning

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

chore(renovate): stop the hourly PR limit acting as a weekly one

ci / ci (pull_request) Successful in 15s

Detaljer

ff187559b0

The shared preset runs Renovate in a single weekly window, so
prHourlyLimit 2 capped every repo at two new PRs per week and
prConcurrentLimit 3 blocked creation entirely while three PRs sat
open. Updates were held for three weeks and tripped
RenovateUpdateHeldTooLong. Drop the hourly limit and let a higher
concurrent limit be the only throttle.

supernaut lade till etiketten

type

chore

2026-09-08 20:00:21 +00:00

supernaut sammanfogade incheckning dcd37f0693 till main

2026-09-08 20:18:43 +00:00

supernaut refererade denna ändringsförfrågan från en incheckning

2026-09-08 20:18:43 +00:00

chore(renovate): stop the hourly PR limit acting as a weekly one (#97)

supernaut refererade denna ändringsförfrågan från en incheckning

2026-10-02 17:57:00 +00:00

chore(renovate): stop the hourly PR limit acting as a weekly one (#97)