-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Move failsafe config out of native profile #21997
Conversation
Thanks for your pull request! The title of your pull request does not follow our editorial rules. Could you have a look?
|
@QuarkusIntegrationTest
@QuarkusIntegrationTest
@ia3andy Have a look through what I did here. I left the I also deprecated the |
Just realized I didn't update the |
Just updated with the tests for the changes. I rebased the commits into a single commit to make it easier to review. |
@edeandrea let's also move to the test directory, then we will just test that everything is also working on gradle |
having |
also (I love the "temporary" here :)) |
So instead of removing I know in Gradle it does separate into a separate source set. |
Although looking at https://github.com/quarkusio/quarkus/blob/main/devtools/gradle/gradle-application-plugin/src/main/java/io/quarkus/gradle/QuarkusPlugin.java#L85 it looks like its aligning the source set name with this name. If we change it, then this will break for anyone already out there. The solution to that would be to add the ability within the gradle plugin to support both source set names. I'm not sure I want to tackle that in this PR. We could add an enhancement for that. |
I think we should have a proper solution for gradle @gastaldi any thoughts? |
It would have a rippling effect as well, since the Gradle plugin also has the To be consistent we'd have to introduce a new source set (something like The new source set would most likely have to become the child of the existing one, so that any tweaks any current users have made will automagically "flow" into this new source set. Then we'd have to update the documentation. And do we also introduce a new task I have lots of experience building Gradle plugins and know how to do this :) Just not sure if its something we want to bite off in this PR or not. I'll leave it to you all to decide. |
Yeah it's maybe too much for one PR. I believe we should try to be iso between buildtools in the long term, so I'll suggest this:
|
That works for me. Should I set this PR as |
@edeandrea if all the test pass locally set it ready yep |
Great I will do that once it finishes. Been going for quite some time already. My machine is super slow. |
@ia3andy Locally the tests are failing at the |
Let see what the CI says here |
@ia3andy looks like CI failed with things like
|
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building b3ce304
Full information is available in the Build summary check run. Failures⚙️ JVM Tests - JDK 11 Windows #- Failing: devtools/cli
📦 devtools/cli✖
✖
✖
✖
⚙️ Maven Tests - JDK 11 #- Failing: integration-tests/maven
📦 integration-tests/maven✖
✖
✖
✖
✖
✖
✖
✖
✖
✖
⚙️ Maven Tests - JDK 11 Windows #- Failing: integration-tests/maven
📦 integration-tests/maven✖
✖
✖
✖
✖
✖
✖
✖
✖
✖
|
@edeandrea run all the failing test (due to snapshot mismatch) with |
I'll try that again today. That's what I did yesterday locally and after 2 hours the neo4j tests were failing |
Its to alleviate some of @gsmet 's concerns about lots of projects may not fully understand that they shouldn't have I agree with you - but I also understand his concern (took me some time to grasp it). The change is a no-op for any existing projects, or for anyone in the future who doesn't want to run ITs outside of native images, and opt-in for people who want to do it for more than native images. If we enabled it by default we'd be enabling functionality for users who may not realize it. I think its a good compromise. |
Well, they have perfectly understood what we have been documented since day 1. For instance:
|
Sorry, I just noticed I was writing |
That's the problem @gsmet Looks like it's time re-evaluate that. There is no magic here with the QuarkusIntegrationTest unless we want to build the app twice, which, imo, isn't a good idea. |
+100 to this |
I'd consider introducing an |
@gsmet this PR does not enable the running of IT by default, is that viable for you? or are you against @QuarkusIntegration* annotations uses "prod" as it has been doing for many releases now? |
@aloubyansky "introducing an integration-test profile" is that a quarkus profile or a maven profile? |
A Quarkus one. With a higher priority than |
after chat with @aloubyansky @geoand the current PR isn't hurting and makes sense for 2.8 but do agree it would be interesting looking into to introduce a "integration" quarkus profile that gets combined with the generated artifact (jar/nativeimage/container with prod static init). But that would also introduce change in behaviours. |
I still feel like we're missing the point. a) things are baked into the built image. We know this. We do it on purpose. I think we've surfaced that we generally have a problem with testing final images that we made worse when we added IMO, I'm +1 for doing this now (for fresh projects) and chasing the fallout. Eric's changes at least make it easier for people to enable integration tests more broadly without having to refactor their pom (for new projects). The fact that we have muddy water around the use of the prod profile is already a problem for native tests right now. So if we're going to fix it, lets fix it. |
@ebullient unless i'm missing something what you write is the same update I made? We have several +1's on this PR; just need to clarify with @gsmet if anything needs updating on docs before 2.8 and if "int" profile idea gets added in for 2.8 or 2.9. |
same. broke it out differently to make sure it was still the same. ;) |
ack - yup. adding failsafe this way is the rational safe next step IMO. |
It's a big -1 on my side. We fix things and then we change the generated projects once we have something working reasonably well. It's definitely a very bad idea to do it the other way around and get the projects of everyone not working properly with You cannot have the notion of |
And in any case, it's too late for 2.8. I won't get structural changes to the generated project merged post CR1. So we have a whole cycle to figure this out and do things properly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to +1 this for merging into main targeting 2.9.
In addition we got agreement on the following for 2.9:
- Document what kind of settings should put in prod profile (@geoand )
avoid putting settings in prod code that is a security concern
Review all the existing guides to make sure things are clearMake sure the quickstarts
don’t promote bad practices (or add proper warnings in the application.properties if it
makes sense)
Use quarkus.profile for explicit config pickup
for 2.9+ (as in probably more like 2.10+):
- make default ITest use a dedicated integration profile for runtime config Support compression for reactive routes and resteasy reactive #24558
- make blog about integration test full story (@geoand / @maxandersen )
Hey @maxandersen I was working on something completely unrelated and came across https://quarkus.io/guides/maven-tooling#build-tool-maven and realized I hadn't updated it as part of this PR. I've just pushed a new commit (& rebased from main). Please take a look (https://github.com/quarkusio/quarkus/pull/21997/files#diff-22914b1e1fa444916b50c249fd5e9ac895c5953f40602207dd83cb0f59c10e5a) and make sure the documentation on that page in this PR looks ok. |
Hey @maxandersen with 2.9 coming soon, I thought we agreed to target this for 2.9? |
I honestly thought this was merged shortly after we agreed. We'll need to put it in 2.10 :/ |
There are some follow up actions we agreed to take that I signed up for. Unfortunately it fell off my radar so I'll do them for 2.10 |
This PR moves the
maven-failsafe-plugin
config out of thenative
profile and into the main profile. This PR coincides with #23488 (that one was originally part of this one before it was moved out to its own PR).The logic is that why should integration tests only be run when building native images? Aren't their results valuable for JVM-based applications as well as apps packaged inside a container?
The history on this PR contains the conversation around this (& also the conversation as to why part of it was split off into a separate PR).