-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gradle Plugin Integration Test should, ideally, actually run the application #1623
Comments
@vorburger I did both a (Maven) build and a |
Hi, the tests annotated with @QuarkusTest will not run the -runner.jar, but the compile classes, this is identical for both Maven and Gradle. |
@stalep I was actually more thinking about an IT for the Gradle built JAR, but you are raising a good point that ideally such a new Gradle IT should cover both the runner JAR as well as a Gradle built native executable, yes. |
related to quarkusio#1623 just for consistency with the Quick Start and our doc on https://quarkus.io/guides/gradle-tooling and https://quarkus.io/guides/gradle-config.html FTR: This change does not actually fix the currently broken Gradle IT.
I gave this some thought today, and wanted to propose a PR with something simple and pragmatic as a starting point (just via a
But given that the Gradle Quick Start still works (even after quarkusio/quarkus-quickstarts#137 and with quarkusio/quarkus-quickstarts@master...vorburger:gradle_v999-SNAPSHOT), what's "broken" here is likely "just" the PS: Also note #1926, but that's more orthogonal (it does not fix this). |
The missing dependency would be |
Thanks! But I do see
FYI note that
... so this (above) technically strictly speaking is not exactly the same way (layout on the file system) of getting dependencies. It should not matter, but if the code which the Gradle plugin uses (which I believe is shared with the Maven plugin, and where @aloubyansky recently did some work to improve things?) somehow relies on finding things laid out in Maven local repo layout, perhaps that's causing this.. Let me try if I can change the IT to be more like IRL (like quickstart) - kind of like #1926 but pushing ever further in that direction, to align IT with actual use.
I'm hitting this on Linux. |
Ha! To my surprise, that actually helped... see #1929 (specifically its 6f4ba31). With #1929, I now get a working JAR built by Gradle in But now the tests fail under Gradle (so to get the JAR you actually need to build it using |
related to quarkusio#1623 just for consistency with the Quick Start and our doc on https://quarkus.io/guides/gradle-tooling and https://quarkus.io/guides/gradle-config.html FTR: This change does not actually fix the currently broken Gradle IT.
see details for why in quarkusio#1926 related to quarkusio#1623
related to quarkusio#1623 just for consistency with the Quick Start and our doc on https://quarkus.io/guides/gradle-tooling and https://quarkus.io/guides/gradle-config.html FTR: This change does not actually fix the currently broken Gradle IT.
see details for why in quarkusio#1926 related to quarkusio#1623
related to quarkusio#1623 just for consistency with the Quick Start and our doc on https://quarkus.io/guides/gradle-tooling and https://quarkus.io/guides/gradle-config.html FTR: This change does not actually fix the currently broken Gradle IT.
see details for why in quarkusio#1926 related to quarkusio#1623
use 'plugins' instead of 'apply plugin' in gradle-it but avoid using mavenLocal() in devtools/gradle-it (see details for why in quarkusio#1926) related to quarkusio#1623 and for consistency with the Quick Start and our doc on https://quarkus.io/guides/gradle-tooling and https://quarkus.io/guides/gradle-config.html
Closing this one as duplicate. |
While #1405 (#1396) will help with future non-regression for Gradle related pure build issues such as e.g. #1323, it does not really e2e test the Gradle built artifact, and thus misses problems such as #1622 and other possible future ones like it.
In fact, we could complete break the Gradle plugin and produce an empty 0 bytes JAR, as long as the Gradle build process itself does not fail, and the current Gradle IT as is would still pass... 😈
To add real coverage to actually start and do an HTTP GET on the Gradle built JAR does not seem terribly difficult, but perhaps one point to first discuss here to agree on what the best way to go about to launch (the equivalent) of
java -jar build/getting-started-runner.jar
from a JUnit is? Do we already do something like this elsewhere in Quarkus (perhaps Maven) ITs which could could & should be used as inspiration? Otherwise I would propose to use (my) https://github.com/vorburger/ch.vorburger.exec, but I thought it was worth first discussing this here before possibly raising a PR...@stalep @jnizet @geoand any input, or even contribution, certainly welcome.
The text was updated successfully, but these errors were encountered: