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>
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. |
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
|
| # Scheduled builds refresh dependency locks before creating the reference artifacts. | ||
| # Refresh them here as well so the candidate uses the same dependency resolution. | ||
| - if [ $CI_PIPELINE_SOURCE == "schedule" ] ; then ./gradlew resolveAndLockAll --write-locks $GRADLE_ARGS; fi |
There was a problem hiding this comment.
After some thought I think, maybe just remove dependencies updates in nightly build?
I do not see any value of that. We have a weekly job that correctly update dependencies by checking 48h cooldown, and we do not have this logic in nightly build.
WDYT?
There was a problem hiding this comment.
I tend to agree, but wouldn't that complicate the gitlab file?
There was a problem hiding this comment.
I think it should simplify it :)
There was a problem hiding this comment.
Let's do that in a follow-up PR.
| # Scheduled builds refresh dependency locks before creating the reference artifacts. | ||
| # Refresh them here as well so the candidate uses the same dependency resolution. | ||
| - if [ $CI_PIPELINE_SOURCE == "schedule" ] ; then ./gradlew resolveAndLockAll --write-locks $GRADLE_ARGS; fi |
There was a problem hiding this comment.
I think it should simplify it :)
|
/merge |
|
View all feedbacks in Devflow UI.
It will be processed automatically as soon as GitHub reports it as mergeable. View in MergeQueue UI.
Use ⏳ Waiting for pull request to become mergeable |
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