Switch to ubuntu-resolute-builder as the default builder

[anthonydahanne]

• replacing Noble
• not addressing the spring-boot-cnb-test-builder still based on Noble yet; it could wait for this PR to be merged first.

Hello Spring friends 👋

This is a candidate PR to upgrade Spring Boot to using the latest Ubuntu LTS: Resolute.

I think it's in a good shape, and would represent progress to Spring users.

Now, I understand you probably don't want to change the builder during a random patch release; so I suggest we let this PR open, and you target it to the proper versions, and on my side I'll keep it up to date against main

Also, if you're open to contributions for upgrading spring-io/spring-boot-cnb-test-builder to Resolute too, I'd be happy to, just tell me and I PR that.

Happy reviewing 📖 ☕ !

[ThomasVitale]

This is great! Does it also solve #51166?

[anthonydahanne]

This is great! Does it also solve #51166?

ah! I just looked at it, and yes, I guess setting the run-image by default is what's missing now.

So yes, this PR should solve that issue too

[mhalbritter]

Hello @anthonydahanne,

thanks for the PR! Just for my understanding: builder-noble-java-tiny was a builder which run image had no shell. This PR switches to ubuntu-resolute-builder, whose default run image is includes a shell. Is that what Paketo recommends? Using the full image by default, and only opting into the tiny image on demand?

[anthonydahanne]

Hello @mhalbritter , sorry for late answer, working on my github filters 🫠 ...

So,

builder-noble-java-tiny was a builder which run image had no shell.

yes

This PR switches to ubuntu-resolute-builder

yes

whose default run image is includes a shell.

yes

Is that what Paketo recommends? Using the full image by default, and only opting into the tiny image on demand?

Yeah, what changed really is that we have less builders than before, and rely more on runImage - we updated samples that way too

WRT tiny and native, I just added a new commit, so that -Pnative and equivalent do use tiny automatically.

How it works:

• In BuildRequest, when BP_NATIVE_IMAGE=true and the default builder is used (and no run image is set explicitly), the run image defaults to paketobuildpacks/ubuntu-resolute-run-tiny.
• Both -Pnative flows now set that env at the same spot where they already mark the build native: Gradle in NativeImagePluginAction, Maven in spring-boot-starter-parent's native profile. So mvn -Pnative spring-boot:build-image and gradle bootBuildImage with the Native Build Tools plugin both pick the tiny run image on their own.
• A user can still override it, e.g. to keep the full run image:

<configuration>
   <image>
     <runImage>paketobuildpacks/ubuntu-resolute-run</runImage>
   </image>
 </configuration>

It also relies on your recent change that turned the stack-id mismatch into a warning rather than an error : ubuntu-resolute-run-tiny carries io.buildpacks.stacks.resolute.tiny while the builder is io.buildpacks.stacks.resolute, so the build now logs a warning and proceeds. Happy to suppress that specific warning for the resolute/tiny pairing if you'd prefer a clean log on the default native path.

This should also close #51166.

[mhalbritter]

I'm thinking about to switch the run image unconditionally to the shell-less variant (as we have now), and if users want to have a shell, they can opt in by changing the run image. This would preserve the same behavior as we have today, and we could drop the changes for the native image case.

Only downside is that we get a warning every build about non-matching stack ids (the same warning pack gives):

Ours:

Warning: Run image stack 'io.buildpacks.stacks.resolute.tiny' does not match builder stack 'io.buildpacks.stacks.resolute'. Stack IDs are deprecated, but the images may not be compatible.

pack's:

Warning: deprecated usage of stack.

The fix for the warning, if we want to diverge from pack behavior: #51166 asked for it (long term solution): skip it when io.buildpacks.base.distro.name / .version or io.buildpacks.stack.distro.name / .version match on both images, drop stack comparison.

Let me talk to the team about that.

[wilkinsona]

I consider our alignment with pack to be a bit higher level than how or if we warn about something. Relaxing the constraint so that we didn't fail achieved that. We should now feel free to refine things from there. As long as we don't start failing again, we'll still be aligned at the level that we need to be.

Having thought about this some more, I don't think the current warnings (either ours or pack's) are particularly helpful as there are situations where the user can't really do anything to fix it. I think it makes sense to change things so that this fairly common scenario is warning free.