Quarkus native ignores 'quarkus.profile' override in native mode

[emakunin]

Describe the bug

Hello,
I'm using quakus native (GraalVM) with AWS lambdas. I have BETA/PROD stages where I want to deploy the same build artifact with different runtime configuration from profile files. But Quarkus native ignores config keys for beta after QUARKUS_PROFILE=beta env variable override in native mode.

Build process takes time, so I want to re-use the same build artifact for both enviroments. Also it is kind of safer to deploy the same binaries that were tested, not generated differently.

Is there a way to achieve my setup? Maybe some GraalVM options to disable profile optimisztions. If no it would be nice to add or at least mention in the docs explicitly. I'd imagine it's quite a common setup so can be useful for others.

Expected behavior

QUARKUS_PROFILE=beta should override profile for native images and load corresponding configuration (beta in this case at runtime. Or at least tell explicitly that it's not possible.

Actual behavior

1. After QUARKUS_PROFILE=beta. Profile changed with a warning to beta with below warning

   2025-01-15 14:25:58,124 WARN  [io.qua.run.con.ConfigRecorder] (main) The profile 'prod' used to build the native image is different from the runtime profile 'beta'. This may lead to unexpected results.
   

2. Quarkus keeps using prod config keys.
3. In the documentation it's written that I can override the mode and there some instructions for integration tests. But being honest it's a bit vaugue for the native image use case. I cannot understand if it's supported or no.

How to Reproduce?

1. I have separate custom profile aware files with the config for each stage: application-prod.configuration, application-beta.configuration. Also some "common/default" values in application.config. The files are in resources.
2. I include the the resources to the native image as

    <quarkus.native.resources.includes>
      resources/**
    </quarkus.native.resources.includes>
   

3. I build service in native mode without any profile overrides (prod used by default)
4. Then I try to select necessary config at runtime using QUARKUS_PROFILE=beta env variable, but the values from the beta config are not read. (I test it using different CORS domains). In the lambda logs I see below warning

    2025-01-15 14:25:58,124 WARN  [io.qua.run.con.ConfigRecorder] (main) The profile 'prod' used to build the native image is different from the runtime profile 'beta'. This may lead to unexpected results.
   

Output of uname -a or ver

Version info: 'GraalVM 22.3.0.1-Final Java 17 Mandrel Distribution'
Java version info: '17.0.5+8'
C compiler: gcc (redhat, x86_64, 8.5.0)
Garbage collector: Serial GC
2 user-specific feature(s)

• io.quarkus.runner.Feature: Auto-generated class by Quarkus from the existing extensions
• io.quarkus.runtime.graal.DisableLoggingFeature: Disables INFO logging during the analysis phase

Output of java -version

Java version info: '17.0.5+8'

Quarkus version or git rev

3.15.1 (LTS)

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

mvn --version
Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)

Additional information

No response

[quarkus-bot]

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

[radcortez]

It is not about profile optimizations. There is no reliable way to change the profile used to build the native image at runtime. This is also not a Quarkus limitation (if we can call it that way).

The native image build executes the static blocks during compilation, meaning that any configuration required / used in static blocks (and dependent code), would use the configuration and profile set at build time. You can change the runtime profile, but all those pieces have already been initialized with a different profile, hence the warning.

[emakunin]

Hi @radcortez,
Thank you for the explanation. So basically it's the only way to proceed: build twice (unless i'm sure that there's no static code using the props).
E.g I pass some api keys as env variables and it works. But for quarkus.http.cors it's always the value from the build profile even if I use environment variables.

It would be cool to mention it explicitly in the docs. Right now it's possible to override and even explained how. But it won't work properly. I spent quite some time debugging =\ Maybe the warning in the doc will help others.

P.S. is there any option for compiler to allow dynamid configs? We have a CD pipeline and building each service for each commit twice is quite slow and expensive.

[radcortez]

Thank you for the explanation. So basically it's the only way to proceed: build twice (unless i'm sure that there's no static code using the props).

Yes, but there is no good way to know which configuration is used in the static code. For instance, REST Providers are created statically, so they use the available configuration from the native image build. After the build and when the native image starts, these providers are already initialized, and any configuration changes has no effect.

E.g I pass some api keys as env variables and it works. But for quarkus.http.cors it's always the value from the build profile even if I use environment variables.

Actually, quarkus.http.cors is a configuration that is not used statically, so it can be changed via a profile in the native executable. I did try it out on one of my projects, and it worked as expected. Maybe you are missing the main file? https://quarkus.io/guides/config-reference#profile-aware-files

It would be cool to mention it explicitly in the docs. Right now it's possible to override and even explained how. But it won't work properly. I spent quite some time debugging =\ Maybe the warning in the doc will help others.

We can add such a warning. Would you like to contribute to it? :)

P.S. is there any option for compiler to allow dynamid configs? We have a CD pipeline and building each service for each commit twice is quite slow and expensive.

No, because this really depends on how the code is written:

static {
 SmallRyeConfig config = ConfigProvider.getConfig().unwrap(SmallRyeConfig.class)
 config.getValue("foo.bar", String.class);
 // do some work
}

This block is executed during the native image build, so any configuration used there will have no effect during runtime.

[emakunin]

Hi @radcortez,

Actually, quarkus.http.cors is a configuration that is not used statically, so it can be changed via a profile in the native executable. I did try it out on one of my projects, and it worked as expected. Maybe you are missing the main file?

You are right! I found a mistake in my setup.

We can add such a warning. Would you like to contribute to it? :)

Yes I can do. I didn't contribute to quarkus so far though, so will need some time to ramp up. Hopefully will find this weekend. If you have a link/wiki handy I'd appreciate. Otherwise no worriess I'll try to find.

[radcortez]

You are right! I found a mistake in my setup.

Excellent!

Yes I can do. I didn't contribute to quarkus so far though, so will need some time to ramp up. Hopefully will find this weekend. If you have a link/wiki handy I'd appreciate. Otherwise no worriess I'll try to find.

A documentation change is pretty straightforward:

• https://github.com/quarkusio/quarkus/blob/main/CONTRIBUTING.md#documentation
• https://github.com/quarkusio/quarkus/blob/ca4576d0f957270117d0c8b85c7964a37f6d578c/docs/src/main/asciidoc/config-reference.adoc
• https://github.com/quarkusio/quarkus/blob/c294d265f4f07a1d11abeb746af029ddf738c723/docs/src/main/asciidoc/building-native-image.adoc

Thank you!