Validate scheduled builds with refreshed dependency locks - #12392
Conversation
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
|
🎯 Code Coverage (details) 🔗 Commit SHA: 43dc4a8 | Docs | View more details | Give us feedback! |
🟢 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. |
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.
More details
The scheduled validation now refreshes dependency locks in the same way as the reference build. The failure path puts both JAR sets in the existing job artifact directory.
🤖 Datadog Autotest · Commit cd311bd · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
AlexeyKuznetsov-DD
left a comment
There was a problem hiding this comment.
Approving, but curious why we are not just excluding lock files from SHA?
|
@AlexeyKuznetsov-DD the lock files do not end up in the jar;) They however help gradle to resolve dependencies. |
|
/merge |
|
View all feedbacks in Devflow UI.
It will be processed automatically as soon as GitHub reports it as mergeable. View in MergeQueue UI.
devflow unqueued this merge request: It did not become mergeable within the expected time |
|
/code blockers |
|
View all feedbacks in Devflow UI.
Checking merge blockers for #12392...
Detected 2 merge blocker(s) to address: 🔴 Blocking
🟠 Pending
|
|
/merge |
|
View all feedbacks in Devflow UI.
It will be processed automatically as soon as GitHub reports it as mergeable. View in MergeQueue UI.
brice.dutheil@datadoghq.com unqueued this merge request |
|
/code blockers |
|
View all feedbacks in Devflow UI.
Checking merge blockers for #12392...
No merge blockers detected. |
|
/merge |
|
View all feedbacks in Devflow UI.
PR already in the queue with status waiting |
|
/merge -c |
|
View all feedbacks in Devflow UI.
|
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
Build pipeline has failing jobs for 7ab3775: What to do next?
DetailsSince those jobs are not marked as being allowed to fail, the pipeline will most likely fail. |
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
Build pipeline has failing jobs for 5bfd05b: What to do next?
DetailsSince those jobs are not marked as being allowed to fail, the pipeline will most likely fail. |
|
/merge |
|
View all feedbacks in Devflow UI.
It will be processed automatically as soon as GitHub reports it as mergeable. View in MergeQueue UI.
The expected merge time in
|
What Does This Do
Refreshes dependency locks in
validate_buildfor scheduled pipelines, matching the lock refresh performed bybuildbefore rebuilding JARs for comparison.Also, when
compareToReferenceJarfails, the reference and candidate JARs will be published as job job artifacts for inspection.Motivation
Scheduled pipelines refresh dependency locks in
buildbefore producing the reference JARs. Butvalidate_builddid not had that step, so it rebuilt candidates from the committed lockfiles which can lead to a different dependency ordering.This became visible after the version catalog requested
dd-instrument-java:0.0.5while thedd-trace-otlockfile still declared0.0.4.Both
buildandvalidate_buildjobs resolved to0.0.5(the jar content was correct), but the different lock file changed dependency input ordering.dd-instrument-javais relocated, and its entries appeared at different positions in thedd-trace-otShadow JAR. While the content was identical, the jar itself had different hash on the different jobs.To prevent that on scheduled pipelines
validate_buildnow applies the same scheduled lock refresh as thebuildjob. Allowing to build jars using the same dependency resolution order.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