jib: jibDockerBuild fails to pull source image from gcr
Description of the issue: Unable to build Docker image from custom base image hosted in gcr with gradle.plugin.com.google.cloud.tools:jib-gradle-plugin:0.9.10
I’ve got Docker on the path: PATH=/Applications/Docker.app/Contents/Resources/bin:…
Already have the image locally after executing:
- gcloud auth configure-docker
- gcloud auth print-access-token | docker login -u oauth2accesstoken --password-stdin https://gcr.io
- docker pull gcr.io/ir-devops-playground/oracle-jdk1.8:alpine3.8
Environment:
- Mac El Capitan 10.11.6
- Docker version 18.06.1-ce, build e68fc7a
jib-gradle-plugin Configuration:
Both my & service IAM account have “Storage Object Viewer” role. Tried 2 authentication approaches:
jib {
from {
image = "gcr.io/ir-devops-playground/oracle-jdk1.8:alpine3.8"
auth {
username = '_json_key'
password = file("${project.rootDir}/ir-devops-playground-33d34617c277.json").text
}
}
}
&
jib {
from {
image = "gcr.io/ir-devops-playground/oracle-jdk1.8:alpine3.8"
auth {
username = 'oauth2accesstoken'
password = 'gcloud auth print-access-token'.execute().text.trim()
}
}
}
Log output:
./gradlew :impactradius-account:jibDockerBuild --stacktrace
Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':impactradius-account:jibDockerBuild'.
Caused by: org.gradle.api.GradleException: Build to Docker daemon failed
at com.google.cloud.tools.jib.gradle.BuildDockerTask.buildDocker(BuildDockerTask.java:118)
....
Caused by: java.io.IOException: 'docker load' command failed with output:
at com.google.cloud.tools.jib.docker.DockerClient.load(DockerClient.java:110)
at com.google.cloud.tools.jib.builder.steps.LoadDockerStep.afterPushBaseImageLayerFuturesFuture(LoadDockerStep.java:92)
at com.google.common.util.concurrent.CombinedFuture$CallableInterruptibleTask.runInterruptibly(CombinedFuture.java:181)
at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:57)
Additional Information:
Originally tried pulling the image from our insecure Nexus Docker repo with allowInsecureRegistries=true but when that didn’t work, so I pushed the image up to gcr.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 21 (17 by maintainers)
Yeah, I think we need to retain the history about how each layer is created even if some history created duplicate layers, which means we need to retain duplicate layers too so that the numbers match.
@briandealwis just keep in mind that there was a reason that we used
LinkedHashSetto remove duplicate layers: #739Duplicate layers can exist but they are not necessary for producing the intended container file system. Only the last of any duplicate layers needs to be there to define the same container. I think we might want to just maintain the layers as is (with duplicates) so that the intended history remains associated with them.