From 85776a858207de4b63b6e244ee127d6adade29fc Mon Sep 17 00:00:00 2001 From: Adi Muraru Date: Tue, 18 Aug 2026 16:47:10 +0200 Subject: [PATCH] fix(renovate): track ghcr.io/adobe/koperator/kafka -jdk tags The 3.9.2 Kafka image was published as 2.13-3.9.2-jdk21.0.11 instead of the plain 2.13-3.9.2 shape prior releases used, so the packageRule's matchCurrentValue/versioning regex (scoped to the plain shape only) couldn't see it as a valid version. Renovate silently had nothing to bump, and PR #302 shipped with DefaultKafkaImage still on 3.9.1. Extend the versioning regex to parse an optional -jdk.. suffix, mapping jdk major/update onto the regex versioning module's build/revision slots so both tag shapes compare correctly against each other. This does not gate jdk-major jumps the way 'compatibility' gates the scala prefix - that's deferred to the same operator-side migration already planned for the apache/kafka 4.x bump. Since this changes which tags are valid for the ghcr.io image line, manually cut over the two DefaultKafkaImage/defaultKafkaImage constants to the now-current 2.13-3.9.2-jdk21.0.11 tag; Renovate will track further -jdk bumps automatically going forward. The ~20 config/samples/**/docs/benchmarks/** references still pinned to 3.9.1 are left for Renovate's own follow-up PR (same customManager/packageRule now covers them) rather than hand-edited here to avoid conflicting with that automated PR. Co-Authored-By: Claude Sonnet 5 --- api/v1beta1/kafkacluster_types.go | 4 ++-- renovate.json | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/api/v1beta1/kafkacluster_types.go b/api/v1beta1/kafkacluster_types.go index 4bc0fe516..4b18e2b49 100644 --- a/api/v1beta1/kafkacluster_types.go +++ b/api/v1beta1/kafkacluster_types.go @@ -58,7 +58,7 @@ const ( DefaultCruiseControlImage = "adobe/cruise-control:3.0.3-adbe-20260722" // renovate: datasource=docker depName=adobe/cruise-control // DefaultKafkaImage is the default Kafka image used when users don't specify it in KafkaClusterSpec.ClusterImage - DefaultKafkaImage = "ghcr.io/adobe/koperator/kafka:2.13-3.9.1" // renovate: datasource=docker depName=ghcr.io/adobe/koperator/kafka + DefaultKafkaImage = "ghcr.io/adobe/koperator/kafka:2.13-3.9.2-jdk21.0.11" // renovate: datasource=docker depName=ghcr.io/adobe/koperator/kafka // DefaultMonitorImage is the default JMX monitor image used when users don't specify it in MonitoringConfig.JmxImage DefaultMonitorImage = "ghcr.io/adobe/koperator/jmx-javaagent:1.5.0" // renovate: datasource=docker depName=ghcr.io/adobe/koperator/jmx-javaagent @@ -131,7 +131,7 @@ const ( defaultKafkaClusterK8sClusterDomain = "cluster.local" // KafkaBroker.spec.container["kafka"].image - defaultKafkaImage = "ghcr.io/adobe/koperator/kafka:2.13-3.9.1" // renovate: datasource=docker depName=ghcr.io/adobe/koperator/kafka + defaultKafkaImage = "ghcr.io/adobe/koperator/kafka:2.13-3.9.2-jdk21.0.11" // renovate: datasource=docker depName=ghcr.io/adobe/koperator/kafka /* Monitor Config */ diff --git a/renovate.json b/renovate.json index 500dfc487..7592e2a9d 100644 --- a/renovate.json +++ b/renovate.json @@ -172,9 +172,9 @@ "matchPackageNames": [ "ghcr.io/adobe/koperator/kafka" ], - "matchCurrentValue": "/^\\d+\\.\\d+-\\d+\\.\\d+\\.\\d+$/", - "versioning": "regex:^(?\\d+\\.\\d+)-(?\\d+)\\.(?\\d+)\\.(?\\d+)$", - "description": "Tag format is -, e.g. 2.13-3.9.1. Verified live against ghcr.io: default docker versioning parses currentVersion as just '2.13' and silently drops everything after the first hyphen, so Renovate can never see a real 3.9.1->3.9.2 bump (only digest-pin updates fire, via the docker pinDigests rule below) - this affects every '# renovate:' annotated occurrence of this image, including the pre-existing api/v1beta1/kafkacluster_types.go constants. Pinning the scala prefix as 'compatibility' (never auto-changed) and parsing the kafka release as major.minor.patch fixes real version comparison. matchCurrentValue excludes the '-jdk' suffixed variant (config/samples/kraft/simplekafkacluster_kraft.yaml) - that one needs a second compatibility slot this single regex can't express, so it deliberately keeps today's (limited but not broken) default-versioning behavior rather than risk a wrong match." + "matchCurrentValue": "/^\\d+\\.\\d+-\\d+\\.\\d+\\.\\d+(-jdk\\d+\\.\\d+\\.\\d+)?$/", + "versioning": "regex:^(?\\d+\\.\\d+)-(?\\d+)\\.(?\\d+)\\.(?\\d+)(?:-jdk(?\\d+)\\.\\d+\\.(?\\d+))?$", + "description": "Tag format is -[-jdk], e.g. 2.13-3.9.1 or 2.13-3.9.2-jdk21.0.11 (the latter shape shipped starting with the 3.9.2 release tag). Verified live against ghcr.io: default docker versioning parses currentVersion as just '2.13' and silently drops everything after the first hyphen, so Renovate can never see a real 3.9.1->3.9.2 bump (only digest-pin updates fire, via the docker pinDigests rule below) - this affects every '# renovate:' annotated occurrence of this image. Pinning the scala prefix as 'compatibility' (never auto-changed) and parsing the kafka release as major.minor.patch fixes real version comparison. The optional '-jdk..' suffix maps jdk major to 'build' and jdk update to 'revision' (Renovate's regex versioning caps out at 5 numeric levels: major/minor/patch/build/revision, each required to be purely numeric, so the always-0 jdk interim segment is matched but not captured); tags without the suffix default build/revision to 0 and still compare correctly against suffixed ones since a differing kafka patch alone already resolves ordering. This does NOT gate jdk-major jumps (e.g. jdk21.x -> jdk25.x) the way 'compatibility' gates scala - that's covered by the same operator-side migration as the apache/kafka 4.x bump below (see docker/kafka/Dockerfile's java_version comment); revisit if jdk25 lands before that migration." }, { "groupName": "kafka docker images (major)",