Centralize smoke app Gradle proxy setup#11575
Conversation
Exercise the two inputs the native smoke apps rely on: a provider-backed environment variable and a provider-backed file forwarded as a Gradle property. This locks in the Gradle 9 migration support that now replaces the old Exec wiring.
Leave the OpenLiberty smoke apps on the Maven wrapper for now. They are the only Maven nested application builds, so a dedicated NestedMavenBuild task would add API surface before there is a pattern to share.
Move nested smoke-test repository policy into the plugin. Nested Gradle builds now pass root proxy properties and load one init script, so individual application settings files no longer need to repeat the same repository blocks.
Let the smoke-test-app init script own nested repository policy. Application settings files now keep only project-specific settings, with Quarkus retaining its plugin version declaration.
Nested smoke-test builds already pass an explicit build-cache flag from the plugin. Removing the per-application CI cache redirects avoids dead settings and fixes the RUM EAR path that pointed outside the cached workspace.
Keep repository proxy init scripts as a smoke app convention so NestedGradleBuild only passes --init-script when callers provide scripts. Enable that convention only when CI=true and forward proxy properties from the outer build in that mode.
Use a Kotlin init script that configures plugin repositories in beforeSettings and registers a beforeProject hook to add Maven proxy repositories before project build scripts add their own repositories. This keeps project repositories available while making the CI proxy repositories first in nested smoke-test builds.
Use Gradle Action callbacks in the Kotlin init script instead of Kotlin DSL closure helpers. This keeps the script on non-Groovy hook overloads while still running early enough to prepend plugin and project Maven proxy repositories.
bric3
added
type: refactoring
comp: tooling
bric3
requested review from
AlexeyKuznetsov-DD,
amarziali,
daniel-romano-DD,
jandro996,
leoromanovsky,
typotter and
vandonr
and removed request for
a team
AlexeyKuznetsov-DD
left a comment
AlexeyKuznetsov-DD
left a comment
There was a problem hiding this comment.
LGTM, but I have a feeling that SmokeTestAppEndToEndTest can be refactored a bit to reuse similar code in tests.
|
/merge |
|
View all feedbacks in Devflow UI.
This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
The expected merge time in
|
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. |
gh-worker-dd-mergequeue-cf854d
Bot
merged commit 387355b
into
master
2 participants
What Does This Do
Moves the smoke-test app Gradle proxy setup into the smoke app build logic.
The smoke app extension now adds the shared init script only for CI nested builds. The init script is Kotlin, runs early enough to affect plugin resolution, and prepends Maven proxy repositories without replacing project repositories.
It also removes duplicated nested repository and cache wiring from smoke apps that can rely on the shared setup.
Motivation
Gradle 9 exposed a few nested-build assumptions in the smoke apps: plugin repositories, CI proxy repositories, and duplicated boilerplate lived in too many places.
Centralizing that setup keeps the smoke apps consistent while preserving app-specific repositories, including the Tomcat repositories that still belong to those builds.
Additional Notes
This keeps the direction focused on Maven proxy injection. Ivy repository handling remains in app-specific builds for now.
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/merge. You can also:/merge --commit-message "..."/merge -c/merge -f --reason "reason"; please use this judiciously, as some checks do not run at the PR-level (note: the PR still needs to be mergeable, this will only skip the pre-merge build)Jira ticket: [PROJ-IDENT]