Skip to content
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

Confusing documentation or behaviour for quarkus.test.profile.tags #35693

Closed
FWest98 opened this issue Sep 1, 2023 · 9 comments · Fixed by #42715
Closed

Confusing documentation or behaviour for quarkus.test.profile.tags #35693

FWest98 opened this issue Sep 1, 2023 · 9 comments · Fixed by #42715
Assignees
Labels
Milestone

Comments

@FWest98
Copy link
Contributor

FWest98 commented Sep 1, 2023

Describe the bug

The configurations options page mentions that quarkus.test.profile.tags controls which tests will be run or not. It also mentions an environment variable name that can be used to set this value. This seems to suggest that this value can be controlled in any of the "standard" ways configuration is handled in Quarkus: through yaml files, environment variables, etc.

However, it turns out that this value is only read from the system properties directly (source), and thus setting this value through an environment variable does not work. Additionally, for some reason, using -Dquarkus.test.profile.tags=xyz in my gradle test command also does not seem to pass this property on after the fork. So for me, the only reason to set this field now it by hardcoding it in the Gradle task configuration as outlined here. This seems very limited and is quite inconvenient.

Expected behavior

Ideally, based on the documentation, I would expect this configuration to work through all normal Quarkus config options. However, if that is not possible (due to startup dependencies - I can imagine), then at the very least I would expect the documentation to be more explicit about this. Ideally, then, the respective gradle property should be passed on to the test runtime JVM as well, to ease the use of this setting.

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

openjdk version "17.0.8.1"

GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.3.0

Build tool (ie. output of mvnw --version or gradlew --version)

Gradle 8.1.1

Additional information

No response

@FWest98 FWest98 added the kind/bug Something isn't working label Sep 1, 2023
@edufolly
Copy link

I went through the same problem. I completely agree with what was said by @FWest98.

@gsmet
Copy link
Member

gsmet commented Aug 19, 2024

@radcortez could you clarify this one?

@radcortez radcortez self-assigned this Aug 20, 2024
@radcortez
Copy link
Member

Yes, this is implemented as a single System property. I guess the reason is because the JUnit Test Extension executes very early in the stack, where we don't have the Config set up yet.

We could start a simple SmallRyeConfig instance with only the default sources, as with #41317. I see no impediment other than extra work during the test initialization. @geoand, you implemented this. Do you know any reason not to?

The documentation does not distinguish specific sources properties (maybe we should consider that).

@radcortez
Copy link
Member

Relates to #10233.

@radcortez
Copy link
Member

Observing https://bugs.openjdk.org/browse/JDK-8276651 with some prototypes. Updating the JDK got rid of the issue.

@geoand
Copy link
Contributor

geoand commented Aug 21, 2024

I see no impediment other than extra work during the test initialization. @geoand, you implemented this. Do you know any reason not to?

Yeah, that should work

@LarsSven
Copy link
Contributor

LarsSven commented Nov 12, 2024

I've just ran into the exact same issue where I would like to set profile tags in the config, but it just did not work. It would be really nice if the config actually listened to this.

Would there be any possibility to implement this?

@geoand
Copy link
Contributor

geoand commented Nov 12, 2024

cc @radcortez

@radcortez
Copy link
Member

I had an initial proposal in #42715, but that obviously didn't work. I believe that #42157 should help get this right. I'll have a look.

@quarkus-bot quarkus-bot bot added this to the 3.18 - main milestone Dec 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants