FR: Shallow pull for oci_pull about rules_oci HOT 2 OPEN

@alexeagle is there reason for us to do this in 2.x?

from rules_oci.

I put a similar idea into #634

instruct crane to be happy with missing blobs on disk (to be done)

If we are only downloading the json manifest and store it, with some additional metadata about where to fetch the final image at runtime, then we probably don't even need crane until runtime.

oci_tarball has to be aware of shallow oci-layouts and create necessary metadata on its tarball manifest so the runtime knows where to get the blobs from

Agree. In my head, I am thinking of a different set of providers to propagate the metadata between build targets.

I think you would not need oci_tarball at all, because you would also want to defer the tarball creation to runtime. So perhaps just storing a tarball manifest (which file should go to which path inside the tarball) would be sufficient.

oci_push needs to know how to deal oci-layouts

There won't be a layout, right?
Just json metadatas on disk and bazel runfiles.

The new "push" here will do a combination of things at runtime:

• Download the base images and verify their sha256 against the stored metadata.
• Compose all image layers/tarballs according to the metadata using relevant runfiles
• Push the result to registry / load image to local docker daemon.

from rules_oci.