Open jregehr opened 7 months ago
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 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.