Curious why --cache-to creates an image index

[mxmeinhold]

Seems the discussion isn't very visible, so promoting this to an issue.
Note that this actually does cause some issues and isn't just me being curious:

• some registries validate that manifests are spec compliant (particularly GCR out of the ones I've dealt with)
• tooling trying to pull the index's children tries to get them as manifests (which of course results in errors)

Discussed in #911

^{Originally posted by mxmeinhold January 11, 2022}
I noticed that docker buildx build --cache-to creates a application/vnd.oci.image.index.v1+json at the cache destination.

This struck me as odd, given that the "manifests" referenced by it seem to be pushed as blobs in my testing, and aren't resolvable as manifests in the registry. This results in some broken expectations for client (e.g. crane config tries to fetch one of the "manifests" as a manifest, which of course fails). I would think this could fairly easily translated to an image manifest, since the application/vnd.buildkit.cacheconfig.v0 seems a good candidate for the config field, and the other entries look to already be layer mediatypes.

Is there some restriction that requires cache be pushed as an image index?

Context:

$ docker buildx version
github.com/docker/buildx v0.5.1-docker 11057da37336192bfc57d81e02359ba7ba848e4a

I'm testing with crane version 0.7.0 and manually inspecting resources that --cache-to pushed to a self hosted distribution spec compliant registry using logs and curl.

[tonistiigi]

moby/buildkit#2251 best place to track this. For the history, you can look at the linked issues from there.