Make dd-trace-java.muzzle reports additional JVM data in test task inputs - #12631
Conversation
This comment has been minimized.
This comment has been minimized.
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
dd-trace-java.muzzle report additional JVM detail as task inputs
dd-trace-java.muzzle report additional JVM detail as task inputsdd-trace-java.muzzle reports additional JVM data in test task inputs
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: aa5d8047e8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
53a4c9e
into
master
What Does This Do
Improve the muzzle directive using
coreJdk(version)fingerprinting in Gradle. This API takes either a JDK version or the Gradle daemon JVM if no version is specifiedcoreJdk(). Now this tracks the actual Java major version, vendor and full runtime/VM versions, while previous it only recored the major version if any.muzzle { pass { coreJdk("25") } }To be more precise, the directive above creates a
muzzle-AssertPass-core-jdktask, running in a worker on the selected JDK 25. It expects the instrumentation's Muzzle checks to succeed with that JDK's platform classes available. With this change, a different JDK vendor or patch/build invalidates the cached result, if the actual JDK install remains the same the result can be reused.Motivation
A JDK patch/build or vendor change should invalidate cached core-JDK checks, even when the requested Java major version stays the same.
Related to the S3 build cache in #12604.
Additional Notes
Use reported JVM metadata, without hashing JDK binaries.
Verified with Gradle on JDK 21: switching
coreJdk("25")from Corretto 25.0.3 to 25.0.4 changes the cache key and runs the check on the selected JDK.Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issue