Investigate SingleProjectIntegrationTest#testBuild_dockerClient getting stuck indefinitely

[mpeddada1]

Officially moving #4299 to an issue for better tracking.

The SingleProjectIntegrationTest#testBuild_dockerClient test is getting stuck indefinitely with no progress:

2024-08-26T10:48:27.892-0400 [DEBUG] [TestEventLogger] com.google.cloud.tools.jib.gradle.SingleProjectIntegrationTest > testBuild_dockerClient STARTED
2024-08-26T10:48:37.334-0400 [LIFECYCLE] [org.gradle.cache.internal.DefaultFileLockManager] 
2024-08-26T10:48:37.334-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2024-08-26T10:48:37.334-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2024-08-26T10:48:37.334-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2024-08-26T10:48:37.334-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2024-08-26T10:48:37.335-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2024-08-26T10:48:37.335-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2024-08-26T10:48:47.334-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2024-08-26T10:48:47.334-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2024-08-26T10:48:47.334-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2024-08-26T10:48:47.335-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2024-08-26T10:48:47.335-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2024-08-26T10:48:47.335-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2024-08-26T10:48:57.334-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2024-08-26T10:48:57.334-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2024-08-26T10:48:57.334-0400 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
. . .

I'm able to reproduce this locally as well with ./gradlew :jib-gradle-plugin:integrationTest --tests com.google.cloud.tools.jib.gradle.SingleProjectIntegrationTest.testBuild_dockerClient.

Where is it getting stuck?

It gets stuck at this line:

jib/jib-core/src/main/java/com/google/cloud/tools/jib/docker/CliDockerClient.java

Line 196 in ff15988

return JsonTemplateMapper.readJson(infoProcess.getInputStream(), DockerInfoDetails.class);

Other Observations

• The process appears to be blocked waiting for a result to be returned from the docker info process. Interestingly, calling just CliDockerClient#info() in the test isn't resulting in the same issue. It is only when we call ./gradlew jibDockerBuild that we run into the test method getting stuck indefinitely.

• We are also running into the same issue when reading the input from a different process (e.g. docker inspect)

Related issues: #4046

[chanseokoh]

Does it need the same fix as in #4048?

[mpeddada1]

Thanks for the link! Hm after trying this out locally, it looks like the same logic as in #4048 still results in the test getting stuck indefinitely (at CharStreams.toString(stdout) now) :

   // Runs 'docker info'.
    Process infoProcess =  docker("info", "-f", "{{json .}}");
    try (InputStreamReader stdout =
        new InputStreamReader(infoProcess.getInputStream(), StandardCharsets.UTF_8)) {

      // CharStreams.toString() will block until the end of stream is reached.
      String output = CharStreams.toString(stdout);

      if (infoProcess.waitFor() != 0) {
        throw new IOException(
            "'docker inspect' command failed with error: " + getStderrOutput(infoProcess));
      }
   return JsonTemplateMapper.readJson(output, DockerInfoDetails.class);

[mpeddada1]

After digging a little further and experimenting with the examples/helloworld sample, it appears that this issue doesn't occur when the following setup is used:

plugins {
  id 'java'
  id 'com.google.cloud.tools.jib' version '3.4.3'
}

sourceCompatibility = 1.8
targetCompatibility = 1.8

repositories {
  mavenCentral()
}

dependencies {
  implementation 'com.google.guava:guava:23.6-jre'
}

jib {
  from {
    image = "openjdk:8"
    platforms {
      platform {
        architecture = "arm64"
        os = "linux"
      }
      platform {
        architecture = "amd64"
        os = "linux"
      }
    }
  }
  to {
    image = "docker-build-test"
  }
}

However, it does end up getting indefinitely stuck when the custom jib.dockerClient is used (as done in the test).