Failed build image by packeto-buldpacks jdk

[heesuk-ahn]

Hi, All

I set the JDK of packeto buildpack in spring boot and this is it.

bootBuildImage {
    buildpacks = ["gcr.io/paketo-buildpacks/adoptium:latest", "gcr.io/paketo-buildpacks/java:latest"]
}

But recently, it suddenly started failing during the build process.

Error Bellow:

Invalid response received when loading image "pack.local/builder/iabgkkeeuy:latest"

If you do not directly inject the buildpack JDK, it works normally. (default liberica)
This is the same situation in CI SERVER as well as my Local PC

Also,

I built it using the pack cli. In this case, an error like this occurs.

command :  pack build build-test --path . --buildpack paketo-buildpacks/ca-certificates --buildpack paketo-buildpacks/azul-zulu 
--buildpack paketo-buildpacks/java

paketo-buildpacks/java
base: Pulling from paketobuildpacks/builder
Digest: sha256:3c5369193865a530cd37b7c86d48fa72ca19f879cb14b5f6aaee671952cfe451
Status: Image is up to date for paketobuildpacks/builder:base
base-cnb: Pulling from paketobuildpacks/run
Digest: sha256:0600ef2dd08ea48fa5d4423e18e4efb1039ff482e5afd3ca33d6993a10079f4b
Status: Image is up to date for paketobuildpacks/run:base-cnb
ERROR: failed to build: downloading buildpack: extracting from registry paketo-buildpacks/azul-zulu: fetching image: resolve auth for ref gcr.io/paketo-buildpacks/azul-zulu@sha256:42754e8954619b0dc022ab69f176c75f29009a7a16463b415f79196a924a95cf: error getting credentials - err: exec: "docker-credential-gcloud": executable file not found in $PATH, out: ``

[dmikusa]

That doesn't sound like a Buildpacks issue. Maybe a missing dependency.
What OS are you using? What version of pack?

[heesuk-ahn]

Thanks for the good suggestions. The same problem occurs when not using a VPN, but �I will test it after registering it in the company registry first. :) and then I will share result later

[backjo]

This was separately reported on paketo-buildpacks/base-builder#473. Just wanted to add that we're independent from these two reporters and also seeing this issue. Setting builder = "paketobuildpacks/builder:0.2.69-base" in the gradle spring boot plugin configuration is a workaround that worked for us.

@dmikusa-pivotal - This is minimally reproducible using the Spring Boot Initializr with a slightly modified configuration -> https://github.com/backjo/broken-buildpack-example . I've setup a Github Action CI run on the repository to demonstrate the error reproducing -> https://github.com/backjo/broken-buildpack-example/runs/6701052679?check_suite_focus=true

[dmikusa]

@backjo I see that your app demo is failing, but there's no clear indication of why (beyond Invalid response received when loading image, which isn't that helpful).

Are you able to reproduce this with pack? pack -v is often more helpful when debugging issues like this. I tried but couldn't get it to reproduce with pack. That would also help to narrow down if the issue you're seeing is a problem specific to the Maven/Gradle integration.

[heesuk-ahn]

@backjo

I tried your solution about setting builder version.
so, it's worked for me 👍

bootBuildImage {
    builder = "paketobuildpacks/builder:0.2.69-base"
    buildpacks = ["gcr.io/paketo-buildpacks/adoptium:latest", "gcr.io/paketo-buildpacks/java:latest"]
}

[backjo]

Still troubleshooting, but it looks like the underlying cause is 2 additional new Docker layers in 0.2.70-base and beyond that are causing the Spring Boot plugins implementation to hit the 127 limit.

[scottfrederick]

There is an explanation of the issue and a few possible work-arounds here: spring-projects/spring-boot#31233 (comment).

[dmikusa]

OK, so there are two issues being reported here:

1. Running Maven/Gradle to build an image with buildpacks and it fails. That is addressed by @scottfrederick's comment: https://github.com/orgs/paketo-buildpacks/discussions/29#discussioncomment-2873763

2. err: exec: "docker-credential-gcloud": executable file not found in $PATH, out: . This error can happen for a few reasons, but it is a local workstation problem. The pack cli will delegate to Docker for authentication, so if you have an entry in your docker.config file for gcr.io it will attempt to use that to authenticate, even if the image it's loading is public. The pack cli doesn't not check if it's public first. This error often happens if you had gcloud client utilities installed and removed them or the install got messed up (sometimes happens on MacOS after doing a system update). There's a few possible fixes: a.) if you don't use gcloud, edit your docker.config file and remove the entry for gcr.io b.) If you use gcloud but removed the tools, install or reinstall them c.) if they are already installed, you may need to reinstall the gcloud credentials helper again. At any rate, once you sort this out pack should start working again. More background here.