The Spring Boot integration with Cloud Native Buildpacks refers to a builder image by name and tag that is hard-coded. The named builder image is used by default if the user does not provide an image name and tag in the Maven or Gradle configuration.

It is important to pin the default to a known version because later versions of a builder might implement a newer and incompatible version of the platform API. For example,

  • Boot 2.3.0.M1 only supports platform API v0.1. It is pinned to cloudfoundry/cnb:0.0.43-bionic, which is the latest builder that supports that API version.
  • Boot 2.3.0.M2 supports platform API v0.1-0.2. It is pinned to cloudfoundry/cnb:0.0.53-bionic, but should be compatible with later builders until the next platform API changes are implemented.

Instead of hard-coding a cloudfoundry/cnb:0.0.x-bionic image tag containing an ordinal version, we could re-tag the builder image with coordinates like spring-boot/cnb:bionic that pins to a given cloudfoundry/cnb tag, then hard-code Spring Boot to that unversioned image name/tag. A manually-triggered CI process could be used to re-tag a newer builder image after validation that it is API-compatible with Boot.

To provide further control, a spring-boot/cnb mirrored image could use a tag scheme that indicates the API version implemented by the image. The CNB builder team could also change their tagging scheme to include an indication of API version, which could make a spring-boot/cnb mirror unnecessary.

Comment From: wilkinsona

I'm not 100% sure that I've understood the proposal correctly, but it sounds like the manually-triggered CI process that would re-tag a newer builder image would result in unrepeatable builds for our users. I think it's important that whatever we offer out-of-the-box in a non-snapshot version of Spring Boot is repeatable.

Comment From: scottfrederick

On further discussion, it would be ideal if Spring Boot could rely on a CNB builder image tagging scheme that not only allows us to use cloudfoundry/cnb images as-is, without re-tagging, but also provides a guarantee of API compatibility for the life of a Boot minor release.

For example, assuming Spring Boot 2.3.0 is released with support for platform API v0.1-0.2, Boot should be able to consume newer builders that contain security updates and CVE remediations while providing API compatibility until 2.3.0 reaches EOL. This might require the team maintaining the CNB builder images tag images in such a way that multiple "branches" of builders can be published simultaneously to allow evolution of the API while providing backward compatibility.

We'll hold off on doing anything with this issue until we have discussions with the CNB team.

Comment From: scottfrederick

The cloudfoundry/cnb builder images are maintained by the CNB Release Engineering team at Pivotal. They agree that supporting multiple builder image lines based on Platform API version, and tagging builder images with a scheme that indicates the Platform API version, is something that they should do for builder consumers. They have created a story in their Pivotal Tracker backlog for this, but haven't committed to a timeline yet.

Comment From: scottfrederick

Marking this as blocked pending status from the CNB Release Engineering team.

Comment From: scottfrederick

Builder images are now being published with tags that specify the platform API version, with the following tags available:

  • cloudfoundry/cnb:bionic-platform-api-0.3
  • cloudfoundry/cnb:bionic-platform-api-0.2
  • cloudfoundry/cnb:bionic-platform-api-0.1

Spring Boot can change the current default from cloudfoundry/cnb:0.0.53-bionic to bionic-platform-api-0.2. Adding #20757 to add support for bionic-platform-api-0.3.