jibDockerBuild fails to pull source image from gcr #991
Comments
|
I think pulling the image is working and the image is successfully built. Note that Jib does not load the base image into your local docker daemon to build an image. The error message is saying Jib failed to run "docker load" which loads the built image into your local docker daemon. The |
|
Hi @LenGillespie , can you try the instructions at https://github.com/GoogleContainerTools/jib/tree/master/jib-gradle-plugin#build-an-image-tarball and see if you can manually load the image into Docker? |
|
|
I think the number of @LenGillespie can you upload the content of |
|
Converted to txt since GitHub didn't accept json: |
|
Yeah, the number of history entries is larger than the number of layer entries. We need to investigate what is going on. And we should also fix the issue that the Docker error output is not being captured. |
|
Oh, I should have excluded empty layer histories when counting the number. |
|
There are 17 history entries. Among them, 5 are empty layers ( |
|
@LenGillespie can you please also include the output of the following: (you might have to docker-pull it first) |
|
@LenGillespie's docker-load shows it loading 4 layers, but the jib history and build output show it only build three layers. Where did layer |
|
From inspect.txt, there are 9 layers in the base image. The base image has 14 history entries, among which 5 are empty, so the numbers match (9 = 14 - 5). All the information is consistent with config.txt from the Jib-built image, so there is no discrepancy so far. The problem I think is that, the base image has duplicate layers: And it looks like Jib removes the duplicate, and we are left with one less layer. The question is, are duplicate layers part of the spec? That is, is it us or the base image that does not follow the image spec? |
|
It's indeed possible to have duplicate layers with the same ID. FROM registry:2
RUN touch /file
RUN chmod 755 /file
RUN chmod 755 /file |
|
|
|
I guess the question here is: do we eliminate duplicate layers and rewrite the layer history, or do we maintain the layers and history? There are no substantial space savings to eliminating the extra layers. |
|
Duplicate 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. |
|
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 |
|
I think once we get the new cache mechanism in, the problem in #739 should not happen anymore since we won't have a cache metadata with a list for each cache entry. |
|
Hi @LenGillespie , we have released version |
|
Thanks. I ended up rebuilding the image with |
|
@LenGillespie thanks for the update. Good to know about how |
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:
Environment:
jib-gradle-pluginConfiguration:Both my & service IAM account have "Storage Object Viewer" role. Tried 2 authentication approaches:
&
Log output:
Additional Information:
Originally tried pulling the image from our insecure Nexus Docker repo with
allowInsecureRegistries=truebut when that didn't work, so I pushed the image up to gcr.The text was updated successfully, but these errors were encountered: