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

Building a native app with a custom profile does not work #3062

Closed
agoncal opened this issue Jul 2, 2019 · 8 comments
Closed

Building a native app with a custom profile does not work #3062

agoncal opened this issue Jul 2, 2019 · 8 comments
Assignees
Labels
kind/bug Something isn't working triage/duplicate This issue or pull request already exists

Comments

@agoncal
Copy link
Contributor

agoncal commented Jul 2, 2019

Describe the bug

Despite the default profiles (dev, test, prod), Quarkus allows to have custom profiles (eg. staging). Activating a custom profile when developping works, but not when building a native app.

Expected behavior

Such command should work. It sets the quarkus-profile to staging and then builds the native app. But in fact, the prod profile is used instead:

$ mvn -Dquarkus-profile=staging clean package -Pnative

Actual behavior

While developping, it is easy to use a custom profile just by setting the quarkus-profile variable and execute:

$ mvn -Dquarkus-profile=staging clean compile quarkus:dev

But when we set the quarkus-profile variable to build a native app, the following command uses the prod profile instead of the staging profile.

$ mvn -Dquarkus-profile=staging clean package -Pnative

To Reproduce

Create any Hello World application and add the following code so it displays the active profile (thanks to ProfileManager.getActiveProfile()):

@ApplicationScoped
public class ApplicationLifeCycle {

    private static final Logger LOGGER = LoggerFactory.getLogger("ApplicationLifeCycle");

    void onStart(@Observes StartupEvent ev) {
        LOGGER.info("The application is starting with profile " + ProfileManager.getActiveProfile());
    }
}

When executing in dev mode, the dev profile is displayed in the console:

$ mvn clean compile quarkus:dev

When setting the quarkus-profile variable to staging, the staging profile is displayed in the console

$ mvn -Dquarkus-profile=staging clean compile quarkus:dev

But when I build a native app using the quarkus-profile variable, the prod profile is displayed in the console, not the staging:

$ mvn -Dquarkus-profile=staging clean package -Pnative

Environment (please complete the following information):

  • Output of uname -a or ver: Darwin iMac-Pro-de-Antonio.local 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64
  • Output of java -version: java version "11.0.3" 2019-04-16 LTS
    Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS)
    Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode)
  • GraalVM version (if different from Java): graalvm-ce-19.0.2
  • Quarkus version or git rev: 0.18.0
@agoncal agoncal added the kind/bug Something isn't working label Jul 2, 2019
@emmanuelbernard
Copy link
Member

@gsmet do you mind doing a first level investigation?

@gsmet
Copy link
Member

gsmet commented Jul 5, 2019

On it.

@gsmet gsmet self-assigned this Jul 5, 2019
@gsmet
Copy link
Member

gsmet commented Jul 5, 2019

@agoncal the last command with native should be install instead of package no? Otherwise the native tests are not executed and the profile is not displayed at all. Or did I miss something?

If you're referring to the profile displayed during the tests, the tests start a totally new process via failsafe so you need to pass the profile there. BTW, the profile should be test by default and it's not the case but it's another issue we need to tackle.

If you're referring to the profile you obtain when running the native executable once you have it, then it's prod by default and you need to specify the profile as the profile is overridable at runtime:

./target/getting-started-1.0-SNAPSHOT-runner -Dquarkus-profile=staging

Then you obtain:

2019-07-05 18:54:36,870 INFO  [ApplicationLifeCycle] (main) The application is starting with profile staging

Not sure I answer your question though so feel free to provide more information if I don't.

@agoncal
Copy link
Contributor Author

agoncal commented Jul 6, 2019

@gsmet Hum.... getting confused here.

Let's take the default behaviour. When I build a native app, the test profile is used by default when testing (I don't have the prod profile as you mentioned in #3119). But once I execute the native app, I get the prod profile.

$ mvn clean install -Pnative

[INFO] --- maven-surefire-plugin:2.22.0:test (default-test) @ configuration-profile ---
[INFO] 
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] [ApplicationLifeCycle] (main) The application is starting with profile test

$ ./configuration-profile-1.0-runner 

INFO  [ApplicationLifeCycle] (main) The application is starting with profile prod

Now, if I specify a specific profile (eg. staging), the tests are executed with this specific profile (which is fine as I am explicitelly specifying it). But when I execute the native app, the profile prod is used instead.

$ mvn -Dquarkus-profile=staging clean install -Pnative

[INFO] --- maven-surefire-plugin:2.22.0:test (default-test) @ configuration-profile ---
[INFO] 
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] [ApplicationLifeCycle] (main) The application is starting with profile staging
 
 
$ ./configuration-profile-1.0-runner 

INFO  [ApplicationLifeCycle] (main) The application is starting with profile prod

So, what you are saying @gsmet is that if I build the native app with a specific profile, the profile is not used (prod instead), right ? The only way to have this specific profile is by passing the variable when executing ($ ./configuration-profile-1.0-runner -Dquarkus-profile=staging). Is that the expected behaviour ?

There are pros and cons in this approach. The pro is that the native app is bundled with all the configuration of all the profiles, and that the same native app can then be executed in dev, prod, staging, .... profile. But that could also be a con. When in production, you want to be sure that the app only has the configuration for prod and that the configuration for dev and staging is not even in the property file (remove the unneeded configuration when building the app).

Again, I don't know what's your take and what you have in mind (cc @emmanuelbernard).

@emmanuelbernard
Copy link
Member

I think we have conflated a few things possibly and will need a clearer doc and maybe some changes. I've started a discussion on Zulip but we will capture it either here or via email.

@gsmet
Copy link
Member

gsmet commented Jul 8, 2019

Let's take the default behaviour. When I build a native app, the test profile is used by default when testing (I don't have the prod profile as you mentioned in #3119). But once I execute the native app, I get the prod profile.

You are pointing to the surefire tests. They don't test native mode. The native mode is tested by the failsafe IT.

If you enable the failsafe one, you will see the native executable is tested with the prod profile.

Now, if I specify a specific profile (eg. staging), the tests are executed with this specific profile (which is fine as I am explicitelly specifying it). But when I execute the native app, the profile prod is used instead.

Again, you're pointing to the JVM tests, not the native tests.

So, what you are saying @gsmet is that if I build the native app with a specific profile, the profile is not used (prod instead), right ? The only way to have this specific profile is by passing the variable when executing ($ ./configuration-profile-1.0-runner -Dquarkus-profile=staging). Is that the expected behaviour ?

Yes it's the expected behavior. So that you can switch to different profiles at runtime.

That can be discussed for sure. But at least, it's behaving as expected (except for the native executable being tested with the prod profile for which I opened an issue).

@emmanuelbernard
Copy link
Member

@emmanuelbernard emmanuelbernard added the triage/duplicate This issue or pull request already exists label Jul 9, 2019
@emmanuelbernard
Copy link
Member

We have created a new issue to track the changes we want to make based on this conversation and others on quarkus-dev
#3150
I'll close hat but please add comments to the new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working triage/duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

3 participants