Repository navigation
Track smoke artifacts and configurable build inputs - #13083
Conversation
🟢 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
No reportable defect was identified in the artifact dependency wiring or lazy GraalVM metadata inputs. Confidence is limited to source inspection.
🤖 Bits Code Review · Commit a4b628d
AlexeyKuznetsov-DD
left a comment
There was a problem hiding this comment.
LGTM. left minor comment
What Does This Do
Track the built smoke application and additional files as test inputs. In particular, a more precise version tracking, using the
releasefile.This adds an
inputs { ... }hook to the smoke-test DSL. Each application can register named input providers through the regular Gradle'sTaskInputsAPI. The Spring and Quarkus native applications use it to track their GraalVM release metadata.Motivation
Smoke tests received application paths through JVM arguments, but the files were absent from their declared inputs! This didn't properly track the application and could allow build-cache reuse of a changed smoke test app.
Moreover application configurations also need to declare the external tools that affect their nested builds.
Additional Notes
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