Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Offline Buildpack cannot find cached JRE #1073

Open
jregehr opened this issue May 2, 2024 · 2 comments
Open

Offline Buildpack cannot find cached JRE #1073

jregehr opened this issue May 2, 2024 · 2 comments

Comments

@jregehr
Copy link

jregehr commented May 2, 2024

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
Copy link
Contributor

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
Copy link
Author

jregehr commented May 10, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants