FR: Shallow pull for oci_pull

[thesayyn]

Currently, base image is input to oci_image. This has some downsides

• Pushing giant blobs to remote action cache is slow and takes more time than building the target from scratch
• Copying blobs from base image into the oci_image output takes time (see #365)
• Downloading the base image from the internet takes time

I am proposing a shallow pull feature that will prevent this from happening by only downloading necessary image metadata such as manifest and config so we can mutate the config and the manifest. We never mutate existing layers so this is safe.

However, it's not as easy it sounds since we have to

• instruct crane to be happy with missing blobs on disk (to be done)
• 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
• oci_push needs to know how to deal oci-layouts, eg knowing how to mount blobs (see https://github.com/google/go-containerregistry/issues/1321). Feature is already there but we might need to change oci_push a little bit for this to work.

We won't be offering this feature by default as we can't be certain every tooling will know how to deal with shallow oci-layouts.

[thesayyn]

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

[sluongng]

I put a similar idea into https://github.com/bazel-contrib/rules_oci/issues/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.

[alexeagle]

Sorry this didn't make our 2.0 roadmap. @sushain97 has some ideas, but it's still in the design space.