Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] Support manifests list (Docker & OCI) #107

Closed
runcom opened this issue Jun 16, 2016 · 9 comments
Closed

[RFE] Support manifests list (Docker & OCI) #107

runcom opened this issue Jun 16, 2016 · 9 comments
Labels
help wanted kind/feature A request for, or a PR adding, new functionality locked - please file new issue/PR

Comments

@runcom
Copy link
Member

runcom commented Jun 16, 2016

No description provided.

@runcom runcom added kind/feature A request for, or a PR adding, new functionality help wanted labels Jul 14, 2016
@SvenDowideit
Copy link

@runcom is this likely to happen soon? or is https://github.com/estesp/manifest-tool the way to go?

@runcom
Copy link
Member Author

runcom commented Jan 6, 2017

@SvenDowideit I'd love estesp's tool merged back here (where it was forked from, skopeo). I have this on my todo but if anyone wants to take it and help, please do so, I don't have any ETA otherwise.

@rhatdan
Copy link
Member

rhatdan commented Jan 6, 2017

I too think this would be good to get these tools merged back. @estesp What do you think?

@runcom
Copy link
Member Author

runcom commented Jan 6, 2017

Note that docker upstream is basically merging Phil's tool in the Docker cli (via a subcommand called "manifest").

@mtrmac
Copy link
Contributor

mtrmac commented Jan 6, 2017

FWIW containers/image, and skopeo, can consume docker schema2 manifest lists (by choosing the current architecture).

That’s by no means a comprehensive support, of course — but it would be nice to flesh out what this ticket means, “support manifest lists” is too vague to ever say “yes, this has happened”.

@lcarva
Copy link

lcarva commented Sep 18, 2018

It would be great if skopeo copy handled manifests lists by copying all the arch specific manifests, and actually create a manifest list. Currently, it only copies a single arch and creates manifest schema v2.

This probably depends on the destination registry being used. Some implementations may not support manifest lists (quay.io at time of writing). It may also only make sense when the destination is a registry, e.g. docker://.

@mtrmac
Copy link
Contributor

mtrmac commented Sep 18, 2018

There is a WIP PR at containers/image#400 , I’m afraid the progress has stalled for some time.

@rhatdan
Copy link
Member

rhatdan commented Apr 25, 2019

Still open issue, though no one is working on it right now, have to gauge priority.

chhsia0 pushed a commit to chhsia0/pipeline that referenced this issue Aug 23, 2019
…mage.

Currently the image digest exporter does not implemented the behavior described
in the resources doc, which says "if there are multiple versions of the image,
the latest will be used." Instead, it reports the digest of `index.json`, which
is an image index. This behavior introduces a usability issue: one of the major
public container registry --- dockerhub --- does not support OCI image indices,
and there are very few tools (if any) that support converting OCI image indices
to docker manifest lists. Skopeo currently only support pushing an OCI image
index that contain only one image. If the index has more than one images, it
requires the user to specify one:
containers/skopeo#107
containers/image#400

Essentially, these limitations make the image digest exporter useless. To make
this feature useful, the exporter could instead implement the following behavior:

1. If there is only one image in `index.json`, report the image's digest.

2. If there are multiple images, report the digest of the full index.

The advantage of this behavior is that, we can immediately use it (in conjunction
of GoogleContainerTools/kaniko#744), yet if multi-image
manifests are more widely supported, the image digest exporter can still support
that without any modification.
chhsia0 pushed a commit to chhsia0/pipeline that referenced this issue Aug 23, 2019
…ne image.

Currently the image digest exporter does not implemented the behavior described
in the resources doc, which says "if there are multiple versions of the image,
the latest will be used." Instead, it reports the digest of `index.json`, which
is an image index. This behavior introduces a usability issue: one of the major
public container registry --- dockerhub --- does not support OCI image indices,
and there are very few tools (if any) that support converting OCI image indices
to docker manifest lists. Skopeo currently only support pushing an OCI image
index that contain only one image. If the index has more than one images, it
requires the user to specify one:
containers/skopeo#107
containers/image#400

Essentially, these limitations make the image digest exporter useless. To make
this feature useful, the exporter could instead implement the following behavior:

1. If there is only one image in `index.json`, report the image's digest.

2. If there are multiple images, report the digest of the full index.

The advantage of this behavior is that, we can immediately use it (in conjunction
of GoogleContainerTools/kaniko#744), yet if multi-image
manifests are more widely supported, the image digest exporter can still support
that without any modification.
tekton-robot pushed a commit to tektoncd/pipeline that referenced this issue Sep 6, 2019
…ne image.

Currently the image digest exporter does not implemented the behavior described
in the resources doc, which says "if there are multiple versions of the image,
the latest will be used." Instead, it reports the digest of `index.json`, which
is an image index. This behavior introduces a usability issue: one of the major
public container registry --- dockerhub --- does not support OCI image indices,
and there are very few tools (if any) that support converting OCI image indices
to docker manifest lists. Skopeo currently only support pushing an OCI image
index that contain only one image. If the index has more than one images, it
requires the user to specify one:
containers/skopeo#107
containers/image#400

Essentially, these limitations make the image digest exporter useless. To make
this feature useful, the exporter could instead implement the following behavior:

1. If there is only one image in `index.json`, report the image's digest.

2. If there are multiple images, report the digest of the full index.

The advantage of this behavior is that, we can immediately use it (in conjunction
of GoogleContainerTools/kaniko#744), yet if multi-image
manifests are more widely supported, the image digest exporter can still support
that without any modification.
@mtrmac
Copy link
Contributor

mtrmac commented Feb 5, 2020

Skopeo has skopeo copy --all after #741.

@mtrmac mtrmac closed this as completed Feb 5, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
help wanted kind/feature A request for, or a PR adding, new functionality locked - please file new issue/PR
Projects
None yet
Development

No branches or pull requests

5 participants