cloudfoundry / java-buildpack

Cloud Foundry buildpack for running Java applications
Apache License 2.0
439 stars 2.58k forks source link

Offline Buildpack cannot find cached JRE #1073

Open jregehr opened 7 months ago

jregehr commented 7 months ago

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:

  1. Clone this repo
  2. git checkout the appropriate version tag
  3. remove a few of the ./config/*.yml files our teams don't need
  4. build the buildpack
  5. 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.

pivotal-david-osullivan commented 6 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.

jregehr commented 6 months ago

@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.