Description
I still have foundations on PCF/TAS 2.11, and therefore must deal with the 1GB size limitation for buidpack uploads. Yes, there are reasons we aren't on TAS 4.0 yet, and yes we are working to mitigate those ASAP.
In the mean time our buidpack update process has been:
- Clone this repo
git checkout
the appropriate version tag- remove a few of the
./config/*.yml
files our teams don't need - build the buildpack
- Rinse and repeat until the built java-buildpack-offline-v*.zip file is under 1GB
This has worked well until last week. It appears a new JRE was released after the Java buildpack release v4.68.0 was released. For v4.68.0,./config/open_jdk_jre.yml
has 11.0.22_12
in the version_lines
list. After we built and uploaded the buildpack to our v2.11 foundation, cf push
fails with this error in the logs:
ERROR Finalize failed with exception #<RuntimeError: Unable to find cached file for https://java-buildpack.cloudfoundry.org/openjdk/bionic/x86_64/bellsoft-jre11.0.23%2B10-linux-amd64.tar.gz>
Unable to find cached file for https://java-buildpack.cloudfoundry.org/openjdk/bionic/x86_64/bellsoft-jre11.0.23%2B10-linux-amd64.tar.gz
It appears part of the buildpack build process downloads a list of JREs and saves a .cached
file in the /build/staging/resources/cache
folder, and that becomes a part of the buidpack zip file.
Here is the problem: even though the ./config/open_jdk_jre.yml
has a list of pinned versions, and those pinned versions are included in the offline buildpack zip file, the buildpack seems to be trying to use the most recent JRE version in the resources/cache/*.cached
file. It is not respecting the pin.
This issue will only affect my team until we are able to upgrade all our foundations and negate the 1GB buildpack upload limit, but it is a bug nonetheless. I think it took a while to manifest itself due to the timing of buildpack vs JRE releases.