fix(renovate): give lock-file maintenance priority under the PR limit #115

Sammanfogat
supernaut sammanfogade 1 incheckning från fix/renovate-lockfile-priority in i main 2026-10-03 00:10:43 +00:00
Ägare

What

A package rule gives lock-file maintenance prPriority: 1 in the shared preset.

Why

RenovateUpdateHeldTooLong fired again for bitborg-web (renovate/lock-file-maintenance and renovate/drizzle-orm-0.x, both held since 2026-09-22).

  • prConcurrentLimit is 6 and branchConcurrentLimit falls back to it. Existing branches count toward the limit.
  • On 2026-09-28 a stale renovate/sharp-0.x branch still existed (bitborg-web PR #226 merged, never deleted, so Renovate would not prune it). Only five new branches fit.
  • Renovate sorts by prPriority, then update type, with lock-file maintenance last. It is the first to starve whenever six or more updates are eligible. The branch-limit-reached decision logs at debug only, so production logs were silent.
  • The same mechanism fits bitborg-infra#487: on 2026-09-21 exactly six PRs were created, and lock-file maintenance was the sixth.

The stale branches were deleted on 2026-10-02, so drizzle-orm should clear on the next Monday run without this change. Lock-file maintenance needs the priority.

Not changed

The limit of 6 stays: a bigger Monday burst queues more CI jobs against the runner cap. Raising it is the alternative if other updates also starve.

Test

renovate-config-validator --strict passes. The sort order was read from Renovate 43 (workers/repository/process/sort.js): prPriority descending comes before update type.

## What A package rule gives lock-file maintenance `prPriority: 1` in the shared preset. ## Why `RenovateUpdateHeldTooLong` fired again for bitborg-web (`renovate/lock-file-maintenance` and `renovate/drizzle-orm-0.x`, both held since 2026-09-22). - `prConcurrentLimit` is 6 and `branchConcurrentLimit` falls back to it. Existing branches count toward the limit. - On 2026-09-28 a stale `renovate/sharp-0.x` branch still existed (bitborg-web PR #226 merged, never deleted, so Renovate would not prune it). Only five new branches fit. - Renovate sorts by `prPriority`, then update type, with lock-file maintenance last. It is the first to starve whenever six or more updates are eligible. The `branch-limit-reached` decision logs at debug only, so production logs were silent. - The same mechanism fits bitborg-infra#487: on 2026-09-21 exactly six PRs were created, and lock-file maintenance was the sixth. The stale branches were deleted on 2026-10-02, so drizzle-orm should clear on the next Monday run without this change. Lock-file maintenance needs the priority. ## Not changed The limit of 6 stays: a bigger Monday burst queues more CI jobs against the runner cap. Raising it is the alternative if other updates also starve. ## Test `renovate-config-validator --strict` passes. The sort order was read from Renovate 43 (`workers/repository/process/sort.js`): `prPriority` descending comes before update type.
supernaut lade till 1 incheckning 2026-10-03 00:09:49 +00:00
fix(renovate): give lock-file maintenance priority under the PR limit
Alla kontroller lyckades
ci / ci (pull_request) Successful in 25s
3e3d84b7cd
Renovate sorts lock-file maintenance after every other update type. With prConcurrentLimit at 6, any week with six or more other eligible updates starves it, and the branch-limit decision is logged at debug only. That is what held bitborg-web's lock-file maintenance from 2026-09-22, and it fits the six updates in bitborg-infra#487.

A package rule with prPriority 1 sorts it first. The limit itself stays, since a bigger Monday burst queues more CI jobs. Validated with renovate-config-validator --strict.
supernaut schemalade den här ändringsförfrågan för automatisk sammanfogning när alla kontroller lyckas 2026-10-03 00:10:28 +00:00
supernaut sammanfogade incheckning fa23561f23 till main 2026-10-03 00:10:43 +00:00
supernaut tog bort grenen fix/renovate-lockfile-priority 2026-10-03 00:10:43 +00:00
Logga in för att delta i denna konversation.
Inga granskare
Ingen milstolpe
Inget projekt
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Förfallodatumet är ogiltigt eller utanför gränserna. Använd formatet "åååå-mm-dd".

Inget förfallodatum satt.

Beroenden

Inga beroenden satta

Referens
bitborg/bitborg-docs!115
Ingen beskrivning angiven.