renovate: align the config with cluster-config #34

Closed
opened 2026-09-22 21:40:22 +02:00 by jlab-bot · 0 comments
Member

Align renovate.json5 with the Renovate configuration of the cluster-config repository (renovate.json there), so both repos behave the same way on the shared jlab-renovate-bot instance.

This body is the approved plan; there is no separate plan comment.

Why now, and what changed underneath

Two of cluster-config's choices were previously wrong for this repo and are now right, because the branch protection on main has caught up: a review requirement and validate-charts as a required check are both active. Several comments in this repo still say the opposite, in those words — they are part of the change, not an afterthought.

Decisions (approved)

  1. Adopt cluster-config's configuration 1:1, including the PR limits and the automerge policy.
  2. platformAutomerge: true — the forge now waits for the required check and the review, which is exactly the condition the current comment names as the one that would make true the better value.
  3. pinDigests off for the chart managers. A digest cannot live in appVersion:, so custom.regex must opt out, as it does in cluster-config. helm-values stays opt-out for now as well, and pinning sidecar digests is a separate decision — every digest change would be a chart patch plus a publish.
  4. Implemented in parallel with #33, by explicit instruction, rather than after its merge as rule 7 of CLAUDE.md would have it. #33 adds a customManagers block to the same file; whichever PR merges second resolves the conflict.

Concrete changes to renovate.json5

  • extends: add config:best-practices, keep :semanticCommitsDisabled. The preset pulls in docker:pinDigests, helpers:pinGitHubActionDigests, :configMigration, :pinDevDependencies, abandonments:recommended, security:minimumReleaseAgeNpm and :maintainLockFilesWeekly. The npm-flavoured ones are inert here; the two that are not are named below.
  • labels: ["dependencies"] → ["renovate"].
  • prHourlyLimit: 4 → 0, prConcurrentLimit: 10 → 100.
  • separateMinorPatch: true (new). Minor and patch then arrive as separate PRs.
  • dependencyDashboard: true set explicitly, as in cluster-config.
  • Global automerge: true with automergeType: "pr" and platformAutomerge: true. Majors included; the safeguard is the review requirement, not the absence of automerge.
  • pinDigests: false for matchManagers: ["custom.regex", "helm-values"], with the reason next to it.
  • helpers:pinGitHubActionDigests will rewrite the workflow files — actions/checkout@v7 becomes a SHA pin. That is wanted (cluster-config keeps it deliberately), but it is a visible, repo-wide diff and belongs in the PR description rather than as a surprise.

Kept on purpose, not aligned away

  • minimumReleaseAge: "3 days" on the automerge path. cluster-config applies the same three days to the dependencies where a merge is expensive; here every merge publishes a chart, so the delay stays. Say so in the comment.
  • ignorePaths: ["template-chart/**"] and the ci/** opt-out — repo-specific, no counterpart there.
  • Every per-chart customManagers block, the nginx even-minor constraint, the qbittorrent tag exclusions and the postUpgradeTasks hook.

Comments and documentation that become false with this change

The repo's own rule is that a comment which lies is worse than no comment. These say the opposite of the new state and must be rewritten in the same PR:

  • renovate.json5, the platformAutomerge: false comment: "validate-charts is not (yet) a required check on either side".
  • renovate.json5, the automerge rule: "Majors stay manual".
  • README.md, "PR policy": the same two statements, plus "Majors are merged by hand".
  • README.md, wherever the required-check situation is described.
  • CLAUDE.md: "A required check per chart is not possible" stays true per chart — but it should now say that validate-charts is required as the single context it reports under.
  • Wiki, in the same round of work (step 5): Renovate (PR policy), Forge-and-Tooling (auto-merge and required checks), Versioning (app-major jumps merged by hand), and CI-CD if it repeats any of it.

Known cost, to be written down rather than discovered

With no hourly limit and 24 charts, the first run after a quiet week can open many PRs at once, and every chart PR starts a k3d install-test. On Gitea a whole matrix runs inside one job on one runner, so these queue rather than fan out. That is the accepted trade of lifting the caps.

Verification

  • renovate-config-validator if available; otherwise a JSON5 parse check, and in any case a careful read against the cluster-config file.
  • The config is not a chart, so no version bump and no install-test matrix entry; the quantity render test runs anyway.
  • State plainly in the PR what could not be verified from this workspace — the instance-side behaviour cannot be tested from here.
Align `renovate.json5` with the Renovate configuration of the **cluster-config** repository (`renovate.json` there), so both repos behave the same way on the shared `jlab-renovate-bot` instance. This body is the approved plan; there is no separate plan comment. ## Why now, and what changed underneath Two of cluster-config's choices were previously wrong for this repo and are now right, because the branch protection on `main` has caught up: **a review requirement and `validate-charts` as a required check are both active.** Several comments in this repo still say the opposite, in those words — they are part of the change, not an afterthought. ## Decisions (approved) 1. **Adopt cluster-config's configuration 1:1**, including the PR limits and the automerge policy. 2. **`platformAutomerge: true`** — the forge now waits for the required check and the review, which is exactly the condition the current comment names as the one that would make `true` the better value. 3. **`pinDigests` off for the chart managers.** A digest cannot live in `appVersion:`, so `custom.regex` must opt out, as it does in cluster-config. `helm-values` stays opt-out for now as well, and pinning sidecar digests is a separate decision — every digest change would be a chart patch plus a publish. 4. Implemented **in parallel with #33**, by explicit instruction, rather than after its merge as rule 7 of `CLAUDE.md` would have it. #33 adds a `customManagers` block to the same file; whichever PR merges second resolves the conflict. ## Concrete changes to `renovate.json5` - `extends`: add **`config:best-practices`**, keep `:semanticCommitsDisabled`. The preset pulls in `docker:pinDigests`, `helpers:pinGitHubActionDigests`, `:configMigration`, `:pinDevDependencies`, `abandonments:recommended`, `security:minimumReleaseAgeNpm` and `:maintainLockFilesWeekly`. The npm-flavoured ones are inert here; the two that are not are named below. - `labels`: `["dependencies"]` → **`["renovate"]`**. - `prHourlyLimit`: `4` → **`0`**, `prConcurrentLimit`: `10` → **`100`**. - `separateMinorPatch`: **`true`** (new). Minor and patch then arrive as separate PRs. - `dependencyDashboard: true` set explicitly, as in cluster-config. - **Global `automerge: true` with `automergeType: "pr"` and `platformAutomerge: true`.** Majors included; the safeguard is the review requirement, not the absence of automerge. - **`pinDigests: false`** for `matchManagers: ["custom.regex", "helm-values"]`, with the reason next to it. - **`helpers:pinGitHubActionDigests` will rewrite the workflow files** — `actions/checkout@v7` becomes a SHA pin. That is wanted (cluster-config keeps it deliberately), but it is a visible, repo-wide diff and belongs in the PR description rather than as a surprise. ### Kept on purpose, not aligned away - **`minimumReleaseAge: "3 days"`** on the automerge path. cluster-config applies the same three days to the dependencies where a merge is expensive; here *every* merge publishes a chart, so the delay stays. Say so in the comment. - **`ignorePaths: ["template-chart/**"]`** and the `ci/**` opt-out — repo-specific, no counterpart there. - Every per-chart `customManagers` block, the nginx even-minor constraint, the qbittorrent tag exclusions and the `postUpgradeTasks` hook. ## Comments and documentation that become false with this change The repo's own rule is that a comment which lies is worse than no comment. These say the opposite of the new state and must be rewritten in the same PR: - `renovate.json5`, the `platformAutomerge: false` comment: "validate-charts is not (yet) a required check on either side". - `renovate.json5`, the automerge rule: "Majors stay manual". - `README.md`, "PR policy": the same two statements, plus "Majors are merged by hand". - `README.md`, wherever the required-check situation is described. - `CLAUDE.md`: "A required check per chart is not possible" stays true **per chart** — but it should now say that `validate-charts` is required as the single context it reports under. - Wiki, in the same round of work (step 5): `Renovate` (PR policy), `Forge-and-Tooling` (auto-merge and required checks), `Versioning` (app-major jumps merged by hand), and `CI-CD` if it repeats any of it. ## Known cost, to be written down rather than discovered With no hourly limit and 24 charts, the first run after a quiet week can open many PRs at once, and **every chart PR starts a k3d install-test**. On Gitea a whole matrix runs inside one job on one runner, so these queue rather than fan out. That is the accepted trade of lifting the caps. ## Verification - `renovate-config-validator` if available; otherwise a JSON5 parse check, and in any case a careful read against the cluster-config file. - The config is not a chart, so no version bump and no install-test matrix entry; the quantity render test runs anyway. - State plainly in the PR what could not be verified from this workspace — the instance-side behaviour cannot be tested from here.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#34