Catch build issue by comparing release artifacts with jardiff after build job#11959
Catch build issue by comparing release artifacts with jardiff after build job#11959bric3 wants to merge 5 commits into
build job#11959Conversation
…er build job The new job adds a `compareToReferenceJar` task (via a new `dd-trace-java.jardiff` plugin) that runs jardiff `--stat --exit-code` against a reference jar (the one from `build` job) and fails on any difference, there should be none since the jar being rebuilt is coming from the same commit in a pipeline.
bric3
requested review from
PerfectSlayer,
amarziali,
erikayasuda,
sameerank and
typotter
and removed request for
a team
This comment has been minimized.
This comment has been minimized.
![datadog-prod-us1-3[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
There was a problem hiding this comment.
More details
Jardiff plugin adds a defensive build-validation gate with proper error handling and module-specific configuration. All error paths are explicit (failures throw GradleException rather than silent skips), reference jar resolution is mandatory by design, and modules without publishable artifacts can disable the task. No behavioral regressions identified.
📊 Validated against 8 scenarios · Open Bits AI session
🤖 Datadog Autotest · Commit 845c485 · What is Autotest? · Any feedback? Reach out in #autotest
🟢 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. |
sarahchen6
left a comment
sarahchen6
left a comment
There was a problem hiding this comment.
Cool! Thanks for addressing my prior comments
| * The same task class supports two plugin-configured modes: | ||
| * - `compareToReferenceJar` wires [candidateJar] to the project's archive output, so Gradle builds | ||
| * that archive before comparing it. | ||
| * - `compareJarFiles` leaves [candidateJar] unset and expects `--candidate-jar=<path>`, so it can |
There was a problem hiding this comment.
it looks like compareJarFiles is not used or referenced anywhere 👀 should we delete this?
There was a problem hiding this comment.
I choose to keep this as I'd like to have a base to compare two files. This came from my other work to compare with master. I'll see if I can wire things differently then.
| @Test | ||
| fun `warns when hashes differ but jardiff reports no differences and hashCheck is disabled`() { | ||
| writeProject( | ||
| taskBody = "hashCheck.set(false)", |
There was a problem hiding this comment.
nit: maybe it makes more sense to rename hashCheck to ignoreHashCheck ? because even when hashCheck.set(false), the hash is still "checked," the result is just skipped
| - cp workspace/dd-trace-ot/build/libs/*.jar reference-artifacts/ | ||
| - ./gradlew --version | ||
| # This will run the shadowJar task and exercise the build cache, allowing to identify build-cache issues | ||
| - ./gradlew compareToReferenceJar -PjardiffReferenceDir="$CI_PROJECT_DIR/reference-artifacts" -PskipTests $GRADLE_ARGS |
There was a problem hiding this comment.
I checked with Codex and it recommends:
| - ./gradlew compareToReferenceJar -PjardiffReferenceDir="$CI_PROJECT_DIR/reference-artifacts" -PskipTests $GRADLE_ARGS | |
| - ./gradlew clean compareToReferenceJar -PjardiffReferenceDir="$CI_PROJECT_DIR/reference-artifacts" -PskipTests $GRADLE_ARGS |
because:
validate_build restores both workspace outputs and Gradle execution history
from the build cache. Because it does not clean first, jar and shadowJar can
be UP-TO-DATE. The job may therefore compare each original JAR with a copy of
itself instead of exercising the build cache. Preserve the reference JARs,
then run clean compareToReferenceJar.
This seems reasonable to me. WDYT?
There was a problem hiding this comment.
Not needed there because the job is new container.
3 participants
What Does This Do
dd-trace-java.jardiffGradle plugin andcompareToReferenceJartask that runs jardiff against built jar artifacts.validate_buildGitLab job that preserves the jars produced by thebuildjob, rebuilds the publishable jars, and compares the rebuilt jars against the original build artifacts.Motivation
This gives CI a focused check for build-cache or rebuild issues where the release artifacts change after the
buildjob, even though they come from the same commit.Additional Notes
This PR intentionally compares artifacts within the same pipeline. Comparing against the fork-point build from
masteris kept for the follow-up branch.Preliminary to #11856, it's basically the same idea, but applied to the pipeline.
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 issueJira ticket: [PROJ-IDENT]