You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
While I can see how it can appear to be, if I'm reading correctly, this isn't actually a bug.
It's explained in Packaging Caveats and is seen because the index.yml file is not versioned with the release. Packaging after the fact will always cause the latest version of a dependency to be requested - if you package ASAP after a release, this will often result in a successful package, however, as in this case, if a new dependency is released after, you will see your current behaviour. It's unfortunate timing that it happened with the JRE dependency, as if it happened with another integration that wasn't used you likely wouldn't see an error.
Have you investigated the setting to change the default allowed file size upload? This has a default of 1GB but can be increased in the configuration settings.
@pivotal-david-osullivan thanks for the response. We are going to up the allowed file size upload.
Another "feature" - the setting controls but cf push max file size and also buildpack upload max file size, but the documentation only says it controls cf push max file size.
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:
git checkout
the appropriate version tag./config/*.yml
files our teams don't needThis 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
has11.0.22_12
in theversion_lines
list. After we built and uploaded the buildpack to our v2.11 foundation,cf push
fails with this error in the logs: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 theresources/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.
The text was updated successfully, but these errors were encountered: