fix(renovate): group mise's talosctl and kubectl with the talos group

[axeII]

Fixes the split you spotted between #3893 (talosctl) and #3834 (talos group).

Why they didn't group

The Talos rule matches on datasource:

matchDatasources: ["docker", "github-releases"],
matchPackageNames: ["/installer/", "/kubelet/", "/talosctl/", ...],

/talosctl/ was already in the list — but mise pins talosctl and kubectl via the aqua backend, and Renovate gives those a datasource that is neither docker nor github-releases. The rule could never reach them.

The labels prove it:

PR	Tool	Backend	Labels	Semantic scope
#3894	yayamlls	github:	renovate/mise, renovate/github-release	feat(github-release)
#3893	talosctl	aqua:	renovate/mise only	feat(deps) ← fell through
#3891	kubectl	aqua:	renovate/mise only	feat(deps) ← fell through

So my github-releases addition in #3889 was correct but only ever helped flate and yayamlls.

The consequence

talosctl proposed 1.14.0 while #3834 only moves the cluster to v1.13.10 — a full minor of client/cluster skew, in two PRs that never had to be reviewed together. (For the record: v1.14.0 is a genuine stable release, prerelease: false; siderolabs just reused beta changelog text in the release body, which reads misleadingly.)

The fix

A second rule with the same groupName, scoped by manager rather than datasource:

{
  description: "Talos Group (mise-pinned client tools)",
  groupName: "talos",
  matchManagers: ["mise"],
  matchPackageNames: ["/talosctl/", "/siderolabs\\/talos/", "/kubectl/", "/kubernetes\\/kubernetes/"],
  group: { commitMessageTopic: "{{{groupName}}} group" },
}

Datasource is deliberately left unconstrained here — constraining it is exactly what failed. kubectl is included because the existing group already covers /kubelet/ (the kubernetesVersion in talenv.yaml), so the client belongs with it.

Effect: the client tools travel in the same PR as the cluster version they target, so a skew like 1.14.0-vs-v1.13.10 is visible in one diff instead of split across two.

Verification

.renovate/groups.json5 parses (13 packageRules, both talos rules resolving to groupName: "talos"). just validate, just flate-test (169 passed), pre-commit all pass.

Renovate config changes can't be fully proven until the next run — expect #3893 and #3891 to be superseded by a combined talos group PR.

Optional follow-up

If you'd rather talosctl never lead the cluster, an allowedVersions constraint could cap it at the talenv.yaml minor. I didn't add it — grouping makes the skew visible, and a hard cap is one more thing to keep in sync.

[bot-akira]

konflate — summary

Note

✅ No rendered changes.

View the full rendered diff →

_{konflate · rendered 4166571 · advisory, not a gate}