QUARKUS_PROFILE=dev and '-Dquarkus.profile=dev' not working for native image

[mhubig]

Describe the bug

Setting QUARKUS_PROFILE=dev or appending the comand line option -Dquarkus.profile=dev to the native image has no effect. The application is always started with the prod profile:

 ERROR: Failed to start application (with profile [prod])

Expected behavior

Native build application should start with the profile provided by setting QUARKUS_PROFILE or appending the argument -Dquarkus.profile=<name>.

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

Linux 8e5df6b21197 6.4.16-linuxkit #1 SMP PREEMPT Fri Nov 10 14:49:23 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

java version "17.0.8" 2023-07-18 LTS Java(TM) SE Runtime Environment Oracle GraalVM 17.0.8+9.1 (build 17.0.8+9-LTS-jvmci-23.0-b14) Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 17.0.8+9.1 (build 17.0.8+9-LTS-jvmci-23.0-b14, mixed mode, sharing)

Mandrel or GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.5.2

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

Maven home: /Users/Markus.Hubig/.m2/wrapper/dists/apache-maven-3.9.5-bin/32db9c34/apache-maven-3.9.5 Java version: 21.0.1, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/graalvm-jdk-21/Contents/Home Default locale: de_DE, platform encoding: UTF-8 OS name: "mac os x", version: "14.1", arch: "aarch64", family: "mac"

Additional information

No response

[quarkus-bot]

/cc @Karm (mandrel), @galderz (mandrel), @zakkak (mandrel,native-image)

[melloware]

Hmmm I could be wrong but Native Build automatically presupposes Production mode right? I don't think you can run in Dev mode in a Native image?

[geoand]

@mhubig what exactly are you trying to achieve?

[yrodiere]

@geoand FWIW I noticed something similar with @QuarkusIntegrationTest...

If I set this in my config:

quarkus.test.integration-test-profile=integrationtest

Then @QuarkusIntegrationTest will start quarkus with the correct profile (-Dquarkus.profile=integrationtest):

Executing "/home/yrodiere/workspaces/main/search.quarkus.io/target/search-quarkus-io-999-SNAPSHOT-runner -Dquarkus.http.port=8081 -Dquarkus.http.ssl-port=8444 -Dtest.url=http://localhost:8081 -Dquarkus.log.file.path=/home/yrodiere/workspaces/main/search.quarkus.io/target/quarkus.log -Dquarkus.log.file.enable=true -Dquarkus.log.category."io.quarkus".level=INFO -Dquarkus.profile=integrationtest -Dfetching.quarkusio.uri=file:///tmp/all6579920155752301763/ -Dquarkus.hibernate-search-orm.elasticsearch.hosts=localhost:42601"

But startup logs seem to indicate -Dquarkus.profile was ignored:

2023-11-24 12:47:00,196 INFO  [io.quarkus] (main) Profile prod activated. 

And indeed, I confirm my integrationtest profile is not active: I set a custom log level for a certain category with that profile, and the level still doesn't appear in logs (I did set the min-level correctly at build time).

From what I can see the line "Profile prod activated" gets the list of profiles from Smallrye Config:

quarkus/core/deployment/src/main/java/io/quarkus/deployment/steps/MainClassBuildStep.java

Lines 271 to 272 in 32047ae

	ResultHandle profiles = mv
	.invokeStaticMethod(ofMethod(ConfigUtils.class, "getProfiles", List.class));

Perhaps there's a regression, with profiles not being set correctly, at least in native mode?

It might be a regression caused by my changes in #36560 ... But I'd certainly like @radcortez 's help to investigate this.

[yrodiere]

It might be a regression caused by my changes in #36560 ... But I'd certainly like @radcortez 's help to investigate this.

Hurray, it's not caused by #36560, because that was only merged in Quarkus 3.6, not in 3.5!

But... that means we really don't know where this is coming from. Any idea @radcortez?

[geoand]

Thanks for checking!

[yrodiere]

Also, related (but not exactly the same problem): #36376

[mhubig]

@mhubig what exactly are you trying to achieve?

We are building a docker container with a native quarkus build. We tried to reproduce a bug locally using the production container. Here is a snippet of our application.properties file:

quarkus.datasource.jdbc.url=jdbc:postgresql:///postgres
quarkus.datasource.jdbc.driver=org.postgresql.Driver

%prod.quarkus.datasource.jdbc.url=jdbc:postgresql:///${CLOUDSQL_DATABASE_NAME}
%prod.quarkus.datasource.username=${CLOUDSQL_USER_NAME}
%prod.quarkus.datasource.password=password
%prod.quarkus.datasource.jdbc.additional-jdbc-properties.cloudSqlInstance=${CLOUDSQL_CONNECTION_NAME}
%prod.quarkus.datasource.jdbc.additional-jdbc-properties.socketFactory=com.google.cloud.sql.postgres.SocketFactory
%prod.quarkus.datasource.jdbc.additional-jdbc-properties.enableIamAuth=true

The prod profile settings ensure we are using the Google Cloud SQL SocketFactory when deploying our container to production, but if we start the container locally we would like to use a local database so we tried to set a different profile.

We can archive this by setting the properties via ENV variables, but we thought this is possible by using profiles ...

[radcortez]

The profiles are set correctly. It is just the log that is off.

But remember, for native images, static init code will use the profile used at build time (because static init is initialized during native image compilation), so you may get unexpected results.

[yrodiere]

The profiles are set correctly. It is just the log that is off.

@radcortez Maybe that's a different issue, but I did get some runtime properties apparently being set to an incorrect value... Here's a reproducer:

• Clone https://github.com/yrodiere/search.quarkus.io: git clone https://github.com/yrodiere/search.quarkus.io.git
• cd search.quarkus.io
• Switch to branch reproducer-quarkus-37177: git switch reproducer-quarkus-37177.
  The main branch should reproduce the problem too, but at least I can guarantee that reproducer-quarkus-37177 won't change.
• See how application.properties contains this:

  quarkus.test.integration-test-profile=integrationtest
  [...]
  quarkus.log.category."io.quarkus.search.app".min-level=TRACE
  %dev,test,integrationtest.quarkus.log.category."io.quarkus.search.app".level=TRACE
  

• Notice how quarkus.log.category."io.quarkus.search.app".min-level is set consistently to the same value regardless of the profile
• Notice that quarkus.log.category."io.quarkus.search.app".level is a runtime property
• Notice that quarkus.log.category."io.quarkus.search.app".level is set only in the integrationtest profile, not in prod
• Run ./mvnw clean verify -Dtest='SearchServiceTest' -Dit.test='SearchServiceIT'
• Go grab a cup of coffee
• Look at the logs
• Ignore ERROR logs; they're unrelated and caused by Hibernate Search being too verbose; that'll be fixed in a future version.
• Notice how unit tests yield TRACE logs such as:

  2023-11-30 11:05:13,863 TRACE [io.qua.sea.app.ind.IndexingService] (executor-thread-1) About to persist: Guide{url='https://quarkus.io/guides/hibernate-orm'}
  

• Notice how integration tests don't yield any TRACE logs, which makes me think the wrong profile is in use (or at least %dev,test,integrationtest.quarkus.log.category."io.quarkus.search.app".level=TRACE is being ignored in the integrationtest profile)