skopeo

skopeo copied to clipboard

I am trying to emulate the docker history command via skopeo, to get the instruction and size for each layer. I see I can use skopeo inspect --config to get the instructions ("created_by"), but it doesn't include the layer sizes. Would it be possible to add that?

Thanks for your report.

Have you seen https://github.com/containers/podman/blob/master/docs/source/markdown/podman-history.1.md ?

Layer sizes are not present in the config; they do exist in the manifest, but right now skopeo inspect can’t show them (other than using --raw, which to a large extent defeats the purpose).

I'm not very familiar with podman. Is it capable of producing the history of an image on a remote registry? Or would I have to pull it first?

@mtrmac Following up on this.

Podman does require pulling the image first (parts of the history it includes is matching with other local images to report base images, if known).

A friendly reminder that this issue had no activity for 30 days.

@mtrmac can we close this?

@lsm5 The “provide layer sizes” part is a duplicate of #641.

I’m not sure to what extent “equivalent of docker history” is relevant — I read that part like a motivating request for the layer sizes rather than a RFE to implement exactly that. If this is actually a RFE for a docker history lookalike, that would be a reasonable RFE to keep track of, in principle, and I don’t see much reason to close it with haste.

I am very late to the game but think that podman history is the way to go. skopeo could expose the command as well but it would be strictly limited to work with the container-storage tranport only which lets me feel we're better off pointing to podman history.

@vrothberg podman is way too heavy for our purposes. Also, it seems like skopeo would already have all the information it needs to report this. Can you re-open this issue?

@rittneje To report which “this” data exactly are you looking for?

parts of the history (Podman) includes is matching with other local images to report base images, if known

… and that can’t very well be done by Skopeo without access to the “other local images”.

@mtrmac We are looking for the size and instruction for each layer. We don't need to know the name of the base image specifically.

A friendly reminder that this issue had no activity for 30 days.

not stale

A friendly reminder that this issue had no activity for 30 days.

not stale

This would be made possible by WIP https://github.com/containers/image/pull/1608 .

A friendly reminder that this issue had no activity for 30 days.

not stale

A friendly reminder that this issue had no activity for 30 days.

not stale

A friendly reminder that this issue had no activity for 30 days.

not stale

BTW I was reminded of skopeo inspect --config; that does contain the instruction.

And layer sizes are available after #1738 .

So is there actually more that needs to be done?

@mtrmac It's pretty inconvenient to have to combine the output from skopeo inspect (sizes) and skopeo inspect --config (instructions), especially because there is nothing to directly link the entries. (You have to go by the order but skip entries with "empty_layer": true.) It would be preferable if skopeo inspect --config included the layer sizes in each history entry, or at least the digest.

Another problem is that skopeo inspect seems to give the compressed layer size, while docker history gives the uncompressed size, so they are not interchangeable.

That’s fair.

--config is defined to be the OCI config format, so any new fields should instead be made to the non---config mode (for possibly to a entirely new mode.)

---

Another problem is that skopeo inspect seems to give the compressed layer size, while docker history gives the uncompressed size, so they are not interchangeable.

That information just isn’t available, without actually pulling and decompressing the data.

That information just isn’t available, without actually pulling and decompressing the data.

Ah, that is unfortunate, but we can live it.

A friendly reminder that this issue had no activity for 30 days.