ci(renovate): label major and override PRs, and record the create-first trap #52

Merged
ullrich merged 1 commit from ci/renovate-labels into main 2026-07-29 14:25:33 +00:00
Owner

The bug behind this

The repo had zero labels — repo and org level. So labels: ["dependencies"] has been silently doing nothing since Renovate was introduced: every PR came out bare, with "labels": [] visible in the run log while the config read as correct.

Renovate can attach labels on Forgejo but cannot create them, and a label that doesn't exist is dropped without any warning. That trap is now written down next to the setting.

Created on the repo and backfilled dependencies onto the 11 open Renovate PRs (Renovate only labels at creation, so existing PRs needed it by hand):

id label purpose
1 dependencies every Renovate PR
2 major never auto-merged, always needs a human
3 security-pin touches a pnpm.overrides CVE pin, not an ordinary dep

Two rules

major on every major bump — these are excluded from auto-merge by design, so they're the set worth filtering for.

security-pin on anything touching pnpm.overrides. Those 13 entries are CVE remediation pins, not dependencies: the correct value for one is the minimum patched version inside the range its consumers expect, not the newest release. Renovate can't know that, so it offers "latest" and produces PRs that are wrong by construction — #44 proposed forcing path-to-regexp 8.x into a tree where express@4.22.2 needs the 0.1.x API, and E2E duly failed. The label makes that distinction visible on the PR instead of requiring the reviewer to reconstruct it.

Both use addLabels, not labels: a labels key inside a packageRule replaces the top-level list, which would have silently dropped dependencies from precisely the PRs most worth filtering.

Verified

Parsed the config and computed effective labels per case rather than eyeballing rule order:

dependencies    patch  -> dependencies
dependencies    major  -> dependencies, major
pnpm.overrides  major  -> dependencies, major, security-pin
pnpm.overrides  patch  -> dependencies, security-pin
devDependencies minor  -> dependencies

Also asserted that every label referenced anywhere in the config now exists on the repo — the check that would have caught the original bug.

Deliberately not included

To keep a labels change to labels:

  • disabling major/minor for pnpm.overrides — the part that actually stops #44/#46/#47 regenerating every week
  • osvVulnerabilityAlerts + a security label — the real replacement for Dependabot security updates

Both belong to the CVE follow-up we discussed, alongside lockFileMaintenance and the react-router 7.17.0 → 7.18.2 fix.

## The bug behind this The repo had **zero labels** — repo *and* org level. So `labels: ["dependencies"]` has been silently doing nothing since Renovate was introduced: every PR came out bare, with `"labels": []` visible in the run log while the config read as correct. Renovate can **attach** labels on Forgejo but **cannot create** them, and a label that doesn't exist is dropped without any warning. That trap is now written down next to the setting. Created on the repo and backfilled `dependencies` onto the 11 open Renovate PRs (Renovate only labels at creation, so existing PRs needed it by hand): | id | label | purpose | |---|---|---| | 1 | `dependencies` | every Renovate PR | | 2 | `major` | never auto-merged, always needs a human | | 3 | `security-pin` | touches a `pnpm.overrides` CVE pin, not an ordinary dep | ## Two rules **`major`** on every major bump — these are excluded from auto-merge by design, so they're the set worth filtering for. **`security-pin`** on anything touching `pnpm.overrides`. Those 13 entries are CVE remediation pins, not dependencies: the correct value for one is the *minimum patched version inside the range its consumers expect*, not the newest release. Renovate can't know that, so it offers "latest" and produces PRs that are wrong by construction — #44 proposed forcing `path-to-regexp` 8.x into a tree where `express@4.22.2` needs the 0.1.x API, and E2E duly failed. The label makes that distinction visible on the PR instead of requiring the reviewer to reconstruct it. Both use **`addLabels`**, not `labels`: a `labels` key inside a `packageRule` *replaces* the top-level list, which would have silently dropped `dependencies` from precisely the PRs most worth filtering. ## Verified Parsed the config and computed effective labels per case rather than eyeballing rule order: ``` dependencies patch -> dependencies dependencies major -> dependencies, major pnpm.overrides major -> dependencies, major, security-pin pnpm.overrides patch -> dependencies, security-pin devDependencies minor -> dependencies ``` Also asserted that **every** label referenced anywhere in the config now exists on the repo — the check that would have caught the original bug. ## Deliberately not included To keep a labels change to labels: - **disabling major/minor for `pnpm.overrides`** — the part that actually stops #44/#46/#47 regenerating every week - **`osvVulnerabilityAlerts` + a `security` label** — the real replacement for Dependabot security updates Both belong to the CVE follow-up we discussed, alongside `lockFileMaintenance` and the react-router 7.17.0 → 7.18.2 fix.
ci(renovate): label major and override PRs, and record the create-first trap
All checks were successful
CI / Dockerfile Package Check (pull_request) Successful in 27s
CI / Security Scan (pull_request) Successful in 49s
CI / Checks (pull_request) Successful in 2m57s
CI / Visual Tests (pull_request) Successful in 2m42s
CI / Journal Image Smoke Test (pull_request) Successful in 4m37s
CI / E2E Tests (pull_request) Successful in 8m20s
3d25eeb846
The repo had ZERO labels, so `labels: ["dependencies"]` had been silently doing
nothing since Renovate was introduced — every PR came out bare, with
`"labels": []` in the run log while the config looked correct. Renovate can
attach labels on Forgejo but cannot create them, and a missing label is dropped
without a warning. Created `dependencies`, `major` and `security-pin` on the
repo, backfilled `dependencies` onto the 11 open Renovate PRs, and wrote the
trap down next to the setting so the next person does not lose an afternoon to
it.

Two labelling rules:

- `major` on every major bump. These are never auto-merged and always need a
  human, so they are worth filtering for.
- `security-pin` on anything touching `pnpm.overrides`. Those 13 entries are CVE
  remediation pins, not dependencies: the right value for one is the minimum
  patched version inside the range its consumers expect, not the newest release.
  Renovate cannot know that, so it offers "latest" and produces PRs that are
  wrong by construction — #44 proposed forcing path-to-regexp 8.x into a tree
  where express@4.22.2 needs the 0.1.x API, and E2E duly failed. Labelling makes
  the distinction visible on the PR.

Both use `addLabels` rather than `labels`, because `labels` in a packageRule
REPLACES the top-level list and would have silently dropped `dependencies` from
precisely the PRs most worth filtering.

Verified by parsing the config and computing effective labels per case:

  dependencies    patch  -> dependencies
  dependencies    major  -> dependencies, major
  pnpm.overrides  major  -> dependencies, major, security-pin
  pnpm.overrides  patch  -> dependencies, security-pin

and asserting every referenced label now exists on the repo.

Deliberately NOT included, to keep a labels change to labels: disabling
major/minor for `pnpm.overrides` (which is what stops #44/#46/#47 regenerating),
and `osvVulnerabilityAlerts` with a `security` label. Both belong to the CVE
follow-up.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X8hNxgYp777FRqYtVmQNaU
ullrich deleted branch ci/renovate-labels 2026-07-29 14:25:35 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
trails-cool/trails!52
No description provided.