jibDockerBuild fails to pull source image from gcr
See original GitHub issueDescription 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.
Issue Analytics
- State:
- Created 5 years ago
- Comments:21 (17 by maintainers)
Top Results From Across the Web
Unauthorized error when build docker image with jib, using a ...
Jib does cache base images, so using an image in a registry doesn't mean Jib will download it over and over. (But of...
Read more >google/jib - Gitter
The jib-maven-plugin maven source jar only includes the code source of the project ... I'm trying to pull eclipse-temurin image, but I'm getting...
Read more >Troubleshooting | Container Registry documentation
ImagePullBackoff error from Google Kubernetes Engine. GKE returns an ImagePullBackoff error when it is unable to pull an image from a registry. The...
Read more >Building Java container images using Jib - Snyk
Getting your application packaged into an image and running in a ... Jib is an open source, 100% Java tool that builds OCI...
Read more >Custom Image Builders | Tilt
Docker is the most common way to build container images, but there are others. ... gradlew jibDockerBuild --image $EXPECTED_REF', deps=['src'])
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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
LinkedHashSet
to 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.