Docker API version is incorrectly reported when '/_ping` calls fail and version should be fixed

[dbaltor]

mvn spring-boot:build-image -Dspring-boot.build-image.imageName="$FULL_IMAGE_NAME" -DskipTests fails in Bitbucket Pipeline with the following error message:

[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:3.4.0:build-image (default-cli) on project PROJECT-NAME: Execution default-cli of goal org.springframework.boot:spring-boot-maven-plugin:3.4.0:build-image failed: Docker API version must be at least 1.41 to support the 'imagePlatform' option, but current API version is 1.24 

It works fine with Spring Boot 3.3.6.

Spring Boot 3.4.0
Bitbucket step image: maven:3.9.5-amazoncorretto-21-al2023

Maven configuration:

            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <goals>
                            <goal>build-info</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <excludes>
                        <exclude>
                            <groupId>org.projectlombok</groupId>
                            <artifactId>lombok</artifactId>
                        </exclude>
                    </excludes>
                    <!-- CONFIG TO RUN BUILDPACKS IN BITBUCKET - begin -->
                    <!-- https://github.com/spring-projects/spring-boot/issues/28387 -->
                    <docker>
                        <bindHostToBuilder>true</bindHostToBuilder>
                    </docker>
                    <image>
                        <env>
                            <BP_JVM_VERSION>${java.version}</BP_JVM_VERSION>
                        </env>
                        <securityOptions/>
                        <buildWorkspace>
                            <bind>
                                <source>/opt/atlassian/pipelines/agent/build/cache-${project.artifactId}.work</source>
                            </bind>
                        </buildWorkspace>
                        <buildCache>
                            <bind>
                                <source>/opt/atlassian/pipelines/agent/build/cache-${project.artifactId}.build</source>
                            </bind>
                        </buildCache>
                        <launchCache>
                            <bind>
                                <source>/opt/atlassian/pipelines/agent/build/cache-${project.artifactId}.launch</source>
                            </bind>
                        </launchCache>
                    </image>
                    <!-- CONFIG TO RUN BUILDPACKS IN BITBUCKET - end -->
                </configuration>
            </plugin>

It might be related to #19945

[vonZeppelin]

This will be fixed in 3.4.1 #43424

[philwebb]

Thanks @vonZeppelin. @dbaltor, feel free to give the SNAPSHOT a go and provide feedback if you want to test the fix.

[dbaltor]

Thanks @philwebb and @vonZeppelin. I've tested the snapshot and I'm afraid it doesn't work either. I've got the same error message after upgrading to the latest SNAPSHOT:

[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:3.4.1-SNAPSHOT:build-image (default-cli) on project PROJECT-NAME: Execution default-cli of goal org.springframework.boot:spring-boot-maven-plugin:3.4.1-SNAPSHOT:build-image failed: Docker API version must be at least 1.41 to support the 'imagePlatform' option, but current API version is 1.24 -> [Help 1]

AS per the error message above and this comment #28387 (comment), it looks like Spring Boot started using a Docker API version not available in Bitbucket pipelines to build the container image.

Is there anything the Spring team might be able to do to solve this?

[philwebb]

I think we depend on newer APIs so we can't easily lower the baseline I'm afraid.

[dbaltor]

Thanks @philwebb. I'd like to pick your brain (as well as anybody else's reading this) to try understanding what might be happening.

Atlassian upgraded BB to use Docker Engine 25 at the beginning of this year. Here's the output of docker version within the pipeline step :

Client:
 Version:           20.10.24
 API version:       1.41
 Go version:        go1.19.7
 Git commit:        297e128
 Built:             Tue Apr  4 18:17:06 2023
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true
Server: Docker Engine - Community
 Engine:
  Version:          25.0.3
  API version:      1.44 (minimum version 1.24)
  Go version:       go1.21.6
  Git commit:       f417435
  Built:            Fri Feb 23 02:38:33 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.7.13
  GitCommit:        7c3aca7a610df76212171d200ca3811ff6096eb8
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

I don't know where the docker API 1.24 is coming from. 🤷‍♂️

[philwebb]

Actually, looking again I wonder if our fix in #43424 is correct. If we don't get a reply, we return the minimum version.

[philwebb]

I can't reopen the #43424 because the branch is gone. We'll use this one to fix it.

[philwebb]

Sorry, it's not #43424. I mean this code.

[philwebb]

I think we need to refine the fix for #40944. IMO, calls to the docker API should use a fixed version number and not attempt to detect the running version. I believe that we should be doing this to protect us against any future changes to the JSON returned from the Docker API.

For most of our calls, we can retain our minimum supported version of 1.24. For calls that have a platform we need to up that to 1.41. Getting the actual API version is useful for error reporting, but I don't think we need to fail or assume v1.24 if a call to /_ping fails.

[dbaltor]

Thank you very much @philwebb. Your work is much appreciated.

[philwebb]

@dbaltor If you get a chance, please try the latest SNAPSHOT again. I haven't actually been able to test things in BitBucket.

[dbaltor]

@philwebb I've just tested and it works like a charm. 🎉 Congrats!

[INFO] Building image '[XXXXX](http://XXXXX)'
[INFO]
[INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder-jammy-java-tiny:latest' 5%
[INFO]  > Pulling builder image '[docker.io/paketobuildpacks/builder-jammy-java-tiny:latest](http://docker.io/paketobuildpacks/builder-jammy-java-tiny:latest)' 12%
[INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder-jammy-java-tiny:latest' 19%
[INFO]  > Pulling builder image '[docker.io/paketobuildpacks/builder-jammy-java-tiny:latest](http://docker.io/paketobuildpacks/builder-jammy-java-tiny:latest)' 25%
[INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder-jammy-java-tiny:latest' 28%
[INFO]  > Pulling builder image '[docker.io/paketobuildpacks/builder-jammy-java-tiny:latest](http://docker.io/paketobuildpacks/builder-jammy-java-tiny:latest)' 36%
[INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder-jammy-java-tiny:latest' 58%
[INFO]  > Pulling builder image '[docker.io/paketobuildpacks/builder-jammy-java-tiny:latest](http://docker.io/paketobuildpacks/builder-jammy-java-tiny:latest)' 100%
[INFO]  > Pulled builder image 'paketobuildpacks/builder-jammy-java-tiny@sha256:34ffa9f27adb71c8df73a99b197d8419ec3725217c10fc9a7430e45d3ddf15a7'
[INFO]  > Pulling run image 'docker.io/paketobuildpacks/run-jammy-tiny:latest' for platform 'linux/amd64' 32%
[INFO]  > Pulling run image 'docker.io/paketobuildpacks/run-jammy-tiny:latest' for platform 'linux/amd64' 100%
[INFO]  > Pulled run image 'paketobuildpacks/run-jammy-tiny@sha256:0c5ac79d549c4b077a7d857631f817f8b573f5da2c109a51f320ee584d44d3f2'
[INFO]  > Executing lifecycle version v0.20.5
[INFO]  > Running creator
<OMITTED>
[INFO]     [creator]     Saving [XXXXX](XXXXX)...