While perform a pull from manifest list of type
`application/vnd.oci.image.index.v1+json` make sure that if more
than one image exists for the same platform then give priority to the
one compressed with `zstd`.
Annotation `io.github.containers.compression.zstd` is expected to be set
for the image compressed with `zstd`.
Signed-off-by: Aditya R <arajan@redhat.com>
Flips dependency of internal and public manifest.List API and introduces
private manifest.List API which will be extended in future for new
features.
[NO NEW TESTS NEEDED]
[NO TESTS NEEDED]
Signed-off-by: Aditya R <arajan@redhat.com>
... to allow us to add more APIs using a new mechanism.
Currently c/image/image exposes images as types.Image, which we can't change;
so, let's define a new API that will return a different type that we can modify
as necessary.
For now, make that new API internal, at least until we fix the way edits
are bundled with data-to-be-edited in types.BlobInfo.
c/image/image continues to exist, but currently only trivially forwards
all calls to the moved c/image/internal/image.
As a minimal proof of concept, none of the users of c/image/image in the repo
have been modified; they now refer to the compatibility forwarders.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Mostly just name changes that should not change behavior,
apart from ioutil.ReadDir -> os.ReadDir avoiding per-item
lstat(2) in some cases.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
- When a variant is autodetected (or specified), always try
a Variant: "" image as well - and only as the last attempt.
This is necessary for images like docker://k8s.gcr.io/pause:3.1 .
NOTE: This includes the case of VariantChoice with a completely
unrecognized variant, even in that case we try Variant: "".
- When a variant is not specified with OverrideArch, or perhaps
not autodetected, try an image with a "base variant" as well.
This is necessary for images like docker://busybox:1.27.2 .
If the available images contain _both_ a Variant: "" and a
Variant: baseVariant image, the two are equivalent in priority
and the outcome is ambiguous; in that case, prefer the
Variant: "" image to more closely match the VariantChoice
made; the caller can always explicitly use
VariantChoice: baseVariant to get the other one (which would
not be the case if we preferred Variant: baseVariant).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Add the manifest.List interface, and implementations for OCIv1 Index and
Docker Schema2List documents.
Add an instanceDigest parameter to PutManifest(), PutSignatures(), and
LayerInfosForCopy, for symmetry with GetManifest() and GetSignatures().
Return an error if the instanceDigest is supplied to destinations which
don't support them, and add stubs that do so even to the transports
which would support it, so that we don't break compilation here.
Add a MultipleImages flag to copy.Options, and if the source for a copy
operation contains multiple images, copy all of the images if we can.
If we can't copy them all, but we were told to, return an error.
Use the generic manifest list API to select a single image to copy from
a list, so that we aren't just limited to the Docker manifest list
format for those cases.
When guessing at the type of a manifest, if the manifest contains a list
of manifests, use its declared MIME type if it included one, else assume
it's an OCI index, because an OCI index doesn't include its MIME type.
When copying, switch from using an encode-then-compare of the original
and updated versions of the list to checking if the instance list was
changed (one of the things we might have changed) or if its type has
changed due to conversion (the other change we might have made). If
neither has changed, then we don't need to change the encoded value of
the manifest.
When copying, when checking for a digest mismatch in a target image
reference, ignore a mismatch between the digest in the reference and the
digest of the main manifest if we're copying one element from a list,
and the digest in the reference matches the digest of the manifest list.
When copying, if conversion of manifests for single images is being
forced, convert manifest lists to the corresponding list types.
When copying, supply the unparsed top level to Commit() by attaching the
value to the context.Context.
Support manifest lists in the directory transport by using the instance
digest as a prefix of the filename used to store a manifest or a piece
of signature data.
Support manifest lists in the oci-layout transport by accepting indexes
as we do images, and stop guessing about Platform values to add to the
top-level index.
Support storing manifest lists to registries in the docker: transport by
using the manifest digest when we're writing one image as part of
pushing a list of them, and by using the instance digest when reading or
writing signature data, when one is specified, or the cached digest of
the non-instanced digest when one is not specified.
Add partial support for manifest lists to the storage transport: when
committing one image from a list into storage, also add a copy of the
manifest list by extracting it from the context.Context. The logic is
already in place to enable locating an image using any of multiple
manifest digests.
When writing an image that has an instanceDigest value (meaning it's a
secondary image), don't try to generate a canonical reference to add to
the image's list of names if the reference for the primary image doesn't
contain a name. That should only happen if we're writing using just an
image ID, which is unlikely, but we still need to handle it.
Avoid computing the digest of the manifest, or retrieving the
either-a-tag-or-a-digest value from the target reference, if we're given
an instanceDigest, which would override them anyway.
Move the check for non-nil instanceDigest values up into the main
PutSignatures() method instead of duplicating it in the per-strategy
helpers.
Add mention of the instanceDigest parameter and its use to various
PutManifest, PutSignatures, and LayerInfosForCopy implementations and
their declarations in interfaces.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>