Enable native-image builds automatically

[dmikusa]

Describe the Enhancement

With #272 we are looking for a key file, filepath.Join(n.ApplicationPath, "META-INF", "native-image", "argfile"). If that file exists, we could assume that the user wants to have a native-image build and automatically enable native-image builds.

Possible Solution

I'm not sure off hand if we can tie into the BP_NATIVE_IMAGE env variable or if we'd need to modify the buildplan. The native-image buildpack says that if you set native-image-application in the buildplan, it'll trigger a native-image build. One of these two options should work.

Motivation

Right now a user has to manually set BP_NATIVE_IMAGE=true to trigger a native-image build. The presence of this file could be a trigger which we can use to infer user intent and automatically enable a native-image build (or at least flip the default from false to true, a user should still be able to opt-out by forcing BP_NATIVE_IMAGE=false).

[sdeleuze]

As just shared with @pivotal-david-osullivan, @scottfrederick and @wilkinsona, currently this file is not reliable way to detect that a native image build should be built for Boot apps because:

• This file is expected to be created only when --exclude-config parameters are needed (currently only when Netty 4.1 is used), so with Maven this is not a reliable trigger for now.
• We just found a bug in Spring Boot 3.0.0 bootBuildImage always trys to create a native image due to bootJar always adding a META-INF/native-image/argfile to the jar spring-projects/spring-boot#33363 that creates unconditionally an empty argfile even when NBT plugin is not applied, so I asked @pivotal-david-osullivan to rollback this change asap because currently every Boot app running ./gradlew bootBuildImage will attempt to create a native image, even for regular JVM app!

If you decide to move forward on this change, you should probably make sure:

• That enough users are not on Spring Boot 3.0.0 anymore
• That META-INF/native-image/argfile is created unconditionally by Spring Boot 3

I can understand the appeal of moving away from env variables to control the default trigger of a native build, but I am not convinced by this "trick" to create empty argfile to act as a trigger for Buildpacks. A META-INF/MANIFEST.MF entry would maybe be cleaner. It would also have the benefit to avoid Boot 3.0.0 users to be impacted by this critical regression.

[dmikusa]

Thanks @sdeleuze we'll have to wait and see how things play out and cautiously move forward.

[anthonydahanne]

We could revisit this situation with Spring Boot 3.1 introducing Spring-Boot-Aot-Processed: true to the jar of a Spring Boot app if it is ready for use in a native app.
Last failed attempt #279 could be reworked to instead just read this new entry

[scottfrederick]

See spring-projects/spring-boot#35153

[dmikusa]

@anthonydahanne @scottfrederick - Seems reasonable to me as a default. If you've enabled AOT processing, then we try to build a native image app. I do think we need an opt-out though, so we might still need BP_NATIVE_IMAGE that way someone could say BP_NATIVE_IMAGE=false and not have native image run.

[sdeleuze]

We begin to have more use cases for AOT on the JVM, see https://twitter.com/sdeleuze/status/1650396526709993474, and we will likely explore and potentially refine this use case as part of Spring Framework 6.1, so I think I am not in favor of considering that the default for an app with AOT metadata should be native, even with an opt-out option. We IMO need a native specific signal.

[sdeleuze]

As discussed with @wilkinsona, if the behavior remains the same on Spring Boot side by setting BP_NATIVE_IMAGE depending on if Native Build Tools plugin has been applied or not, that's lowers my original concern. Said otherwise, as far as https://github.com/sdeleuze/spring-jvm-aot samples should continue to generate a JVM container after those changes, I am fine.

The remaining lower concern I have is that if in the future we introduce a more first class support for AOT optimizations on the JVM, it would be tempting the use this AOT signal to set -Dspring.aot.enabled=true and get JVM + AOT as the default behvior. If we switch to native with pack by default with AOT processing enabled, that would be a breaking change if we decide to change the behavior in the future. I guess I am a bit afraid we could regret that move later, but up to you to decide.

[scottfrederick]

As described in spring-projects/spring-boot#35205, the manifest attribute that should be used to automatically enable native builds is Spring-Boot-Native-Processed.

[anthonydahanne]

great! so this entry will be in 3.1.0-RC2, right?!

[scottfrederick]

so this entry will be in 3.1.0-RC2, right?!

Yes, that's right.

[anthonydahanne]

Hello all,
Work is almost complete (pending PR reviews paketo-buildpacks/native-image#258 and #359 then publication of paketo buildpacks and builders).
Still, here's a taste of how it would look like:

1. Pure Maven style:

./mvnw -P native spring-boot:build-image

2. Build with Maven and then OCI image with pack

./mvnw -P native package
pack build -p target/spring-boot-demo-0.0.1-SNAPSHOT.jar my-image

3. When writing those lines I was wondering if a pure pack style could work as well, something like: We also added the detection of the native build if the user provides the BP_MAVEN_ACTIVE_PROFILES="native" environment variable:

pack build my-image --env BP_MAVEN_ACTIVE_PROFILES="native"

but I believe during detect phase, there's gonna be no way to infer the user is about to build native; hence I don't think we'll do better than: pack build my-image --env BP_NATIVE_IMAGE=true --env BP_MAVEN_ACTIVE_PROFILES="native"

(you'll notice the new BP_MAVEN_ACTIVE_PROFILES env. variable that was very recently added)

Please tell me if my assumption about 3. is wrong.

---

Meanwhile, I invite you all to check out this running example demo'ing 1. and 2., thanks to Spring Boot 3.1.0-RC2 and the publication of my buildpacks PRs to my own DockerHub repo

[sdeleuze]

For 3, if there is no way to infer one --env with the other, maybe worth documenting somewhere. Otherwise, looks good to me.