You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Six open PRs (#20, #90, #103, #123, #125, #144) each bump one member of a dependency
set that has to move as a unit. Every one of them fails CI or is premature, because
kcp sdk 0.31.x pins k8s 0.35.x while 0.32.x pins 0.36.x — and the platform we deploy
into still runs kcp 0.31.
Renovate has no knowledge of that constraint, so it rediscovers the same upgrade from
six entry points and re-proposes each one after every rebase. Drafting them is a
per-PR band-aid, not a fix.
Two related gaps:
apigen (tools.lock) ships from the kcp sdk repo and must always equal the github.com/kcp-dev/sdk version in go.mod. Renovate treats them as unrelated —
that is how chore(deps): update module apigen to v0.32.3 - autoclosed #103 drifted to 0.32.3 while go.mod was on 0.31.2.
KCP_VERSION in the Makefile — the kcp server binary the integration tests run
against — is not tracked by Renovate at all, and has already drifted once by hand.
extractVersionTemplate is required because releases are tagged v0.31.6 while the
Makefile value is unprefixed.
allowedVersions caps rather than disables, so patch updates within the line
(e.g. sdk 0.31.6 → 0.31.7) still flow. Grouping sdk + apigen + KCP_VERSION means the
three can no longer drift apart.
When the platform moves to kcp 0.32
Delete the four cap rules in one commit. The held PRs then rebase and go green —
except the multicluster-provider one, which additionally needs the deprecated sigs.k8s.io/controller-runtime/pkg/scheme.Builder in api/v1alpha1/groupversion_info.go
migrated to runtime.NewSchemeBuilder.
Problem
Six open PRs (#20, #90, #103, #123, #125, #144) each bump one member of a dependency
set that has to move as a unit. Every one of them fails CI or is premature, because
kcp sdk 0.31.x pins k8s 0.35.x while 0.32.x pins 0.36.x — and the platform we deploy
into still runs kcp 0.31.
Renovate has no knowledge of that constraint, so it rediscovers the same upgrade from
six entry points and re-proposes each one after every rebase. Drafting them is a
per-PR band-aid, not a fix.
Two related gaps:
apigen(tools.lock) ships from the kcp sdk repo and must always equal thegithub.com/kcp-dev/sdkversion in go.mod. Renovate treats them as unrelated —that is how chore(deps): update module apigen to v0.32.3 - autoclosed #103 drifted to 0.32.3 while go.mod was on 0.31.2.
KCP_VERSIONin the Makefile — the kcp server binary the integration tests runagainst — is not tracked by Renovate at all, and has already drifted once by hand.
Solution
Add to
packageRules:And add a
customManagersentry so KCP_VERSION is tracked and grouped with the sdk:extractVersionTemplateis required because releases are taggedv0.31.6while theMakefile value is unprefixed.
allowedVersionscaps rather than disables, so patch updates within the line(e.g. sdk 0.31.6 → 0.31.7) still flow. Grouping sdk + apigen + KCP_VERSION means the
three can no longer drift apart.
When the platform moves to kcp 0.32
Delete the four cap rules in one commit. The held PRs then rebase and go green —
except the multicluster-provider one, which additionally needs the deprecated
sigs.k8s.io/controller-runtime/pkg/scheme.Builderinapi/v1alpha1/groupversion_info.gomigrated to
runtime.NewSchemeBuilder.