Gradle quarkusIntTest and specific test profile resolves build properties from prod for YAML config

[kdubb]

Describe the bug

When quarkus.test.native-image-profile is used with quarkusIntTest and the configuration is provided via YAML, build time configuration properties are resolved from the prod profile instead of the profile specified via quarkus.test.native-image-profile.

The following YAML configuration specifies an invalid credentials provider for RabbitMQ, but it should never be encountered during quarkusIntTest because the profile is specified as itest.

quarkus:
  test:
    native-image-profile: itest

"%itest":
  greeting:
    name: itest

"%prod":
  quarkus:
    rabbitmq:
      credentials-provider: prod

This will fail when running ./gradlew quarkusIntTest; even though it should pass.

If you change to using an equivalent application.properties the tests pass as expected.

Expected behavior

The prod profile is completely ignored when a different profile is selected using quarkus.test.native-image-profile.

Actual behavior

Build time properties are pulled from prod regardless of the specified quarkus.test.native-image-profile.

How to Reproduce?

With the reproducer below configured as is, running ./gradlew quarkusIntTest will fail because the container will not start with the error java.lang.RuntimeException: unable to find credentials provider of type default.

If you remove/rename the application.yaml and rename the application.properties.bak to application.properties, running ./gradlew quarkusIntTest will succeed as expected.

inttest-profile.zip

Output of uname -a or ver

macOS 13.1

Output of java -version

Oracle JDK 17.0.5

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.15.0 & 2.14.3

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

Gradle 7.6

Additional information

No response

[quarkus-bot]

/cc @glefloch, @quarkusio/devtools

[kdubb]

I originally tried using regular configuration properties but they all worked as expected. I then turned to using the property I was seeing the error with in our build, which was the RabbitMQ property.

The only thing I can reason is that it's a build time property but I am not quite as sure of that as the language I used when submitting the issue.

[kdubb]

In search of a workaround, I found that ./gradlew -Dquarkus.profile=itest quarkusIntTest works.

[glefloch]

@kdubb there is no itest profile applied by default.
@geoand would it make sense ?

[kdubb]

@glefloch Correct, itest is a profile I created for integration testing. I selected it for integration testing via quarkus.test.native-image-profile.

The configuration property is somewhat misnamed but it is supposed to be used for integration tests; actually it has been renamed to quarkus.test.integration-test-profile via #29826.

As pointed out above, running this with an equivalent application.properties uses the correctly selected itest profile.

[geoand]

@kdubb there is no itest profile applied by default. @geoand would it make sense ?

This is essentially what #24581 is about, right?

[glefloch]

@kdubb there is no itest profile applied by default. @geoand would it make sense ?

This is essentially what #24581 is about, right?

Exactly

[geoand]

Build time properties are pulled from prod regardless of the specified quarkus.test.native-image-profile.

This is the expected behavior, or am I missing something?

[kdubb]

I don't think it is. If you've chosen a profile for integration tests via quarkus.test.native-image-profile then that profile should be used. Right now it seems like prod is used to build the artifact and then the same artifact is run with the profile selected via native-image-profile.

Also, when application.properties is used instead of YAML, the native-image-profile is used for both the build and the execution. Basically it results in the behavior I would expect.

[geoand]

If you've chosen a profile for integration tests via quarkus.test.native-image-profile then that profile should be used. Right now it seems like prod is used to build the artifact and then the same artifact is run with the profile selected via native-image-profile.

Yes. that's what I'm saying is expected. Unless quarkus.profile is set when building the artifact, prod will be used as the build time profile.

quarkus.test.native-image-profile is only used for the runtime profile.

It's pretty confusing I'll admit, but it's the current expected behavior

[kdubb]

Confusing might be an understatement. Why does application.properties use native-image-profile for both?

[kdubb]

I recently switched to use Quarkus integration tests from our own Gradle solution and it was a couple hours or more of debugging and figuring out why our itest configuration was seemingly not working for certain options.

[geoand]

Confusing might be an understatement. Why does application.properties use native-image-profile for both?

No idea

[geoand]

Is this still a problem?

[kdubb]

I'm not sure because we use the workaround (for both our versions against 2.16.x and 3.2.x)... we're stilling in the process of switching.

Previously you seemed to think it was correct but I'm not sure which behavior you thought was correct considering it operates differently with application.properties versus application.yaml.

[geoand]

I have no recollection unfortunately :(

[kdubb]

Well for the record, here is the current doc warning for the quarkus.test.integration-test-profile configuration:

Which says it can be "launched" using an alternate profile using the quarkus.test.integration-test-profile configuration option. If you build with prod and launch with a different profile, then the build time properties will still be locked to prod.

Given the above and the fact that when using application.properties the application is both built and launched using the profile selected with quarkus.test.integration-test-profile, I'd say that is the correct behavior; to build and launch using the quarkus.test.integration-test-profile.

[geoand]

Good point

[mhagnumdw]

In search of a workaround, I found that ./gradlew -Dquarkus.profile=itest quarkusIntTest works.

I ended up arriving at this solution before even seeing this thread. Still, thanks @kdubb e @geoand !

From the documentation of the quarkus.test.integration-test-profile property, I thought that this profile was used at build time and runtime of the application started by the integration test.

After trying for a while, what made me think about passing -Dquarkus.profile=itest in integration tests, was this sentence

The default Quarkus runtime profile is set to the profile used to build the application

here: https://pt.quarkus.io/guides/config-reference#default-runtime-profile