build: refactor reference parsing for oci image layouts

[jedevc]

⬆️ Follow up to #1173.

We allow any valid image reference format for the oci-layout, not just limiting to name@digest, we additionally allow images of the form name:tag@digest now.

The name of the reference is used to find the local directory to lookup the store in, while the tag and digest are attached to a random identity to generate the dummy reference sent to the oci-layout context.

This separation of the target to replace and the value to replace it with ensures that any tag or digest set in the client is properly sent across to the server. The tag, while not relevant now, may become relevant at some point in the future for the server, so we can should send it across for now.

[tonistiigi]

Why the handwritten parsing and not just using the reference library?

[jedevc]

Why the handwritten parsing and not just using the reference library?

From the early implementation in #1173 (comment): need to add "dummy.io", because reference.Parse*() funcs require we do not start with a '/'. The reference library doesn't allow a valid path as the name, so we can only include OCI images in the current directory 😅

[tonistiigi]

We should still do the validation of digest on client side. If it is a tag, we should resolve it on the client side as well.

[tonistiigi]

Requiring digest is very painful for the user. We should just support directory (optional tag), and find the digest on client side if possible.

[jedevc]

Have added logic for doing some basic tag resolution as well as some digest verification. Unfortunately, the hand-written parsing is still required.

[jedevc]

cc @deitch (thought you might be interested in this one)

[deitch]

Thanks for cc'ing me @jedevc . I am interested.

I always have to remind myself of the current behaviour, just to evaluate what this does. 😁

The prior was oci-layout:///path/to/image@sha256:<hash>. It would then look in /path/to/image/blobs/sha256/<hash> to find the manifest/index.

This changes it to also support oci-layout:///path/to/image:tag, so it can read index.json for the tag, and then find the manifest/index from there? That is much nicer.

Based on the code, it looks like any form will work, e.g. I have seen many that "override" the index.json to include many images, not just many tags, and I think that would work here?

[deitch]

Should we add some examples to the docs/README for it?

[jedevc]

Ah, yup, have updated the reference docs for it no, to explain the new tags behavior 👍 It's a lot neater now that we don't have to explain about requiring a digest in the name 🎉