Description
Setting a non-wildcard JVM version for an OCI image via the BP_JVM_VERSION
env var in the maven or gradle plugin (as proposed in the docs) will lead to failing builds, if the the JVM version is not the most recent version.
So it might work in the beginning when setting the current version, but once a newer version is out (leading to a new builder version) the build will fail.
See paketo-buildpacks/bellsoft-liberica#8.
I would have created a PR for the docs, but I'm not quite sure what the best solution is.
Pinning the builder
image would work but it's a bit cumbersome to find out a builder version.
What I came up with is this, but it's really not straightforward:
reg tags gcr.io/paketo-buildpacks/builder | grep base-platform-api
At the moment this results in gcr.io/paketo-buildpacks/builder:0.0.429-base-platform-api-0.3
.
But then how to find out the matching JVM version? Again, not straightforward:
skopeo inspect docker://gcr.io/paketo-buildpacks/builder:0.0.429-base-platform-api-0.3 | grep bellsoft-liberica
And then look up JDK version in release, e.g. here: https://github.com/paketo-buildpacks/bellsoft-liberica/releases/tag/v2.13.0
So just delete the paragraph about BP_JVM_VERSION
?
Any other ideas?
Activity
wilkinsona commentedon Aug 12, 2020
Switching to a wildcard as @nebhale suggests in paketo-buildpacks/bellsoft-liberica#8 seems like the best bet to me.
[-]Maven/Gradle Plugin docs: Specifying non-wildcard BP_JVM_VERSION is bound to lead to failing builds[/-][+]Use wildcard in BP_JVM_VERSION with image building[/+]Use Java version wildcard in image building docs
Fix test for Java version in image building docs
schnatterer commentedon Aug 13, 2020
Thanks @wilkinsona and @scottfrederick.
For people looking for a way to get deterministic builds it might be helpful to know that the JDK version can be pinned via the builder. For example by setting a
gcr.io/paketo-buildpacks/builder:0.0.429-base-platform-api-0.3
asbuilder
.Would this be a helpful addition to the docs?
scottfrederick commentedon Aug 13, 2020
@schnatterer Spring Boot uses the Paketo builder by default, but users can choose to use other builders and buildpacks instead. For this reason we try to keep the Boot docs from containing details that are specific to the way Paketo does things. We chose to use
BP_JVM_VERSION
as an example of setting an environment variable for a builder because it's something people are likely to want to do, but we also qualified that example withThe following example assumes that the default builder defines a BP_JVM_VERSION property ...
to try to make it clear that it is dependent on the builder being used. As you've seen, this simple example has required a small amount of effort to stay in sync with Paketo recommendations and docs.This technique for pinning the JDK/JRE version by pinning the builder version looks like something that is better left to the Paketo documentation.