Restore Confluent versions to Kafka Muzzle checks

[AlexeyKuznetsov-DD]

What Does This Do

Adds the Confluent Maven repository as an explicit Muzzle version source for all Kafka instrumentations that test org.apache.kafka artifacts.

Muzzle now combines the Maven Central version list obtained through the existing Depot proxy/fallback flow with Confluent's -ce, -ccs, and other published Kafka versions.

Motivation

Depot previously returned Confluent metadata for some org.apache.kafka coordinates. After Depot was corrected to behave as a Maven Central proxy, those Confluent versions were no longer discoverable by Kafka Muzzle ranges, even though exact Confluent artifacts remained downloadable.

Without an explicit Confluent Muzzle repository, compatibility checks could remain green while silently dropping Confluent version coverage. Declaring the upstream directly makes that coverage intentional and independent of Depot's Maven Central metadata behavior.

Additional Notes

• Exact dependency downloads continue to use the normal Gradle repository order, with Depot preferred in CI.
• This follows the existing confluent-schema-registry-4.1 Muzzle repository pattern.
• PR Skip latest broken Kafka Connect 7.x POMs #12160 demonstrates the intended -ce and -ccs compatibility coverage.

Validation:

• Spotless checks for all five affected Kafka instrumentation modules.
• Dry-run planning for all five affected Muzzle tasks with the CI Depot proxy configured.

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Once approved, use merge queue to merge the PR

Jira ticket: N/A

[datadog-prod-us1-6]

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 69.74% (+11.79%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 8e05f86 | Docs | Datadog PR Page | Give us feedback!}

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	14.06 s	13.90 s	[+0.5%; +1.9%] (maybe worse)
startup:insecure-bank:tracing:Agent	12.94 s	13.02 s	[-1.2%; -0.0%] (maybe better)
startup:petclinic:appsec:Agent	16.99 s	16.74 s	[+0.7%; +2.3%] (maybe worse)
startup:petclinic:iast:Agent	17.00 s	16.96 s	[-0.5%; +1.0%] (no difference)
startup:petclinic:profiling:Agent	16.64 s	16.85 s	[-2.3%; -0.2%] (maybe better)
startup:petclinic:sca:Agent	16.87 s	16.64 s	[+0.3%; +2.4%] (maybe worse)
startup:petclinic:tracing:Agent	16.16 s	16.02 s	[-0.1%; +1.8%] (no difference)

Commit:8e05f866 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[pr-commenter]

Kafka / producer-benchmark

Parameters

	Baseline	Candidate
baseline_or_candidate	baseline	candidate
git_branch	master	alexeyk/restore-kafka-muzzle-confluent-versions
git_commit_date	1786368529	1786400164
git_commit_sha	4373ec0	8e05f86

See matching parameters

	Baseline	Candidate
ci_job_date	1786401380	1786401380
ci_job_id	1939468080	1939468080
ci_pipeline_id	130088818	130088818
cpu_model	Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
jdkVersion	11.0.25	11.0.25
jmhVersion	1.36	1.36
jvm	/usr/lib/jvm/java-11-openjdk-amd64/bin/java	/usr/lib/jvm/java-11-openjdk-amd64/bin/java
jvmArgs	-Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=15002 -Dhttps.proxyHost=127.0.0.1 -Dhttps.proxyPort=15002 -Dhttp.nonProxyHosts=localhost	*.localhost
vmName	OpenJDK 64-Bit Server VM	OpenJDK 64-Bit Server VM
vmVersion	11.0.25+9-post-Ubuntu-1ubuntu122.04	11.0.25+9-post-Ubuntu-1ubuntu122.04

Summary

Found 0 performance improvements and 0 performance regressions! Performance is the same for 3 metrics, 0 unstable metrics.

See unchanged results

scenario	Δ mean throughput
scenario:not-instrumented/KafkaProduceBenchmark.benchProduce	same
scenario:only-tracing-dsm-disabled-benchmarks/KafkaProduceBenchmark.benchProduce	same
scenario:only-tracing-dsm-enabled-benchmarks/KafkaProduceBenchmark.benchProduce	same

[datadog-prod-us1-6]

Confluent metadata is fail-open: all five changed Muzzle planners succeeded with zero -ce/-ccs tasks when the added endpoint was unavailable, allowing CI to silently retain Central-only coverage.

_{📊 Validated against 8 scenarios · Open Bits AI session}

_{🤖 Datadog Autotest · Commit 8e05f86 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}

[datadog-prod-us1-6]

Fail closed when Confluent metadata contributes no versions

CI can remain green with none of the Confluent compatibility coverage this PR is intended to restore.

Assertion details

• Input: Run any affected Kafka Muzzle task while Maven Central is reachable and https://packages.confluent.io/maven/ is unavailable.
• Expected:Declaring this repository to restore Confluent coverage should fail planning when it contributes no Confluent versions. The complete fix requires Muzzle plugin support for a required repository (or an equivalent contribution assertion), plus a buildSrc regression test covering a reachable Central repository and an unavailable required extra repository.
• Actual:With the added URL returning HTTP 502, direct Aether queries for kafka-clients, connect-runtime, and kafka-streams contained only Central versions. All five changed Muzzle dry-runs nevertheless returned BUILD SUCCESSFUL and planned zero -ce/-ccs tasks.

Was this helpful? React 👍 or 👎
_{🤖 Datadog Autotest · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}

[pr-commenter]

Kafka / consumer-benchmark

Parameters

	Baseline	Candidate
baseline_or_candidate	baseline	candidate
git_branch	master	alexeyk/restore-kafka-muzzle-confluent-versions
git_commit_date	1786368529	1786400164
git_commit_sha	4373ec0	8e05f86

See matching parameters

	Baseline	Candidate
ci_job_date	1786401401	1786401401
ci_job_id	1939468083	1939468083
ci_pipeline_id	130088818	130088818
cpu_model	Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
jdkVersion	11.0.25	11.0.25
jmhVersion	1.36	1.36
jvm	/usr/lib/jvm/java-11-openjdk-amd64/bin/java	/usr/lib/jvm/java-11-openjdk-amd64/bin/java
jvmArgs	-Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=15002 -Dhttps.proxyHost=127.0.0.1 -Dhttps.proxyPort=15002 -Dhttp.nonProxyHosts=localhost	*.localhost
vmName	OpenJDK 64-Bit Server VM	OpenJDK 64-Bit Server VM
vmVersion	11.0.25+9-post-Ubuntu-1ubuntu122.04	11.0.25+9-post-Ubuntu-1ubuntu122.04

Summary

Found 0 performance improvements and 0 performance regressions! Performance is the same for 3 metrics, 0 unstable metrics.

See unchanged results

scenario	Δ mean throughput
scenario:not-instrumented/KafkaConsumerBenchmark.benchConsume	same
scenario:only-tracing-dsm-disabled-benchmarks/KafkaConsumerBenchmark.benchConsume	unsure [+96.780op/s; +10171.912op/s] or [+0.032%; +3.348%]
scenario:only-tracing-dsm-enabled-benchmarks/KafkaConsumerBenchmark.benchConsume	unsure [+584.910op/s; +10270.016op/s] or [+0.315%; +5.540%]

[bric3]

It looks like the proper fix, thanks!

[AlexeyKuznetsov-DD]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-08-12 16:28:23 UTC ℹ️ Start processing command /merge

---

2026-08-12 16:28:29 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 2h (p90).

---

2026-08-12 16:38:07 UTC ❌ MergeQueue: The build pipeline contains failing jobs for this merge request

Build pipeline has failing jobs for 54ac298:

• check_build_src

⚠️ Do NOT retry failed jobs directly (why?).

What to do next?

• Investigate the failures and when ready, re-add your pull request to the queue!
• If your PR checks are green, try to rebase/merge. It might be because the CI run is a bit old.
• Any question, go check the FAQ.

Details

Since those jobs are not marked as being allowed to fail, the pipeline will most likely fail.
Therefore, and to allow other builds to be processed, this merge request has been rejected and the pipeline got canceled.

[AlexeyKuznetsov-DD]

/merge -f --reason "Skip MQ since Muzzle not tested on MQ, it is already tested in PR"

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-08-12 17:40:10 UTC ℹ️ Start processing command /merge -f --reason "Skip MQ since Muzzle not tested on MQ, it is already tested in PR"

---

2026-08-12 17:40:14 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 0s (p90).

---

2026-08-12 17:40:23 UTC ℹ️ MergeQueue: This merge request was merged

Warning

This change was merged without running any pre merge CI checks

Reason: Skip MQ since Muzzle not tested on MQ, it is already tested in PR