Error if base image registry uses V2 Schema1

A user in gitter.im/google/jib reported

Caused by: com.google.cloud.tools.jib.image.LayerPropertyNotFoundException: Diff ID not available for digest-only layer
    at com.google.cloud.tools.jib.image.DigestOnlyLayer.getDiffId (DigestOnlyLayer.java:50)
    at com.google.cloud.tools.jib.builder.steps.PreparedLayer.getDiffId (PreparedLayer.java:93)
    at com.google.cloud.tools.jib.image.json.ImageToJsonTranslator.getContainerConfiguration (ImageToJsonTranslator.java:142)
    at com.google.cloud.tools.jib.builder.steps.PushContainerConfigurationStep.call (PushContainerConfigurationStep.java:63)
    at com.google.cloud.tools.jib.builder.steps.StepsRunner.lambda$pushContainerConfiguration$9 (StepsRunner.java:359)
    at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly (TrustedListenableFutureTask.java:125)
    at com.google.common.util.concurrent.InterruptibleTask.run (InterruptibleTask.java:69)
    at com.google.common.util.concurrent.TrustedListenableFutureTask.run (TrustedListenableFutureTask.java:78)
    at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)
    at java.lang.Thread.run (Thread.java:834)

The only place where DigestOnlyLayer is created is ImageToJsonTranslator.toImage(V21ManifestTemplate), meaning it happens only when the registry returns (or returned once in the past if Jib uses a cached manifest) the legacy V2 Schema 1 manifest. Then the toImage(V21ManifestTemplate) is called only in PullBaseImageStep. (There are two call sites in it.)

The obvious workaround is to make the registry return V2.2 manifest or use a different registry that supports V2.2. (But if you have ever used --offline or referenced a base image with a digest (e.g., sha256:xxx, Jib may have cached V2.1 manifests locally at $HOME/.cache/google-cloud-tools-java/jib/images (on Linux), so you may have to delete the folder to clear cached V.2.1 manifests first.)

Note, V2 Schema1 manifest is deprecated in Docker: https://docs.docker.com/engine/release-notes/#19030

Deprecate image manifest v2 schema1 in favor of v2 schema2. Future version of Docker will remove support for v2 schema1 althogether. moby/moby#39365

[chanseokoh]

@zalym the last time I checked, I didn’t have any problem pushing to AWS ECR. Not to mention there are a lot of users using AWS. I think something particular about your environment or setup is causing a failure.

In any case, your issue is different from this issue, so if you would like us to investigate, please open a new issue and help us get more information.

[chanseokoh]

However when using the REST API to query the manifest, a v2.1 manifest is returned unless the header Accept: application/vnd.docker.distribution.manifest.v2+json is sent.

Yes, you should set the Accept header to let the registry know what you can handle. You may also consider accepting an OCI manifest (application/vnd.oci.image.manifest.v1+json), Docker manifest list (application/vnd.docker.distribution.manifest.list.v2+json), or an OCI index (application/vnd.oci.image.index.v1+json).

And given that Docker currently displays a conspicuous deprecate notice for v2.1, we probably won’t work on this issue. I guess you have no problem using v2.2?

# quay.io still defaults to v2.1
$ docker push quay.io/...
The push refers to repository [quay.io/...]
...
[DEPRECATION NOTICE] registry v2 schema1 support will be removed in an upcoming release.
Please contact admins of the quay.io registry NOW to avoid future disruption.
More information at https://docs.docker.com/registry/spec/deprecated-schema-v1/