`buildah inspect` does not work for remote image manifests

[arewm]

If I run buildah inspect on a remote image index, it returns a result. It does not if the remote image is an image manifest.

Image index:

$ buildah inspect quay.io/podman/hello
{
    "schemaVersion": 2,
    "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
    "manifests": [
        {
            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
            "size": 427,
            "digest": "sha256:43de9874507eaa8ffd88eac885b672b1dfc57cc583d9ad920850f97f19809f8f",
            "platform": {
                "architecture": "amd64",
                "os": "linux"
            }
        },
[...]

Image manifest:

$ buildah inspect quay.io/podman/hello@sha256:43de9874507eaa8ffd88eac885b672b1dfc57cc583d9ad920850f97f19809f8f
Error: importing settings: quay.io/podman/hello@sha256:43de9874507eaa8ffd88eac885b672b1dfc57cc583d9ad920850f97f19809f8f: image not known

But a tool like skopeo does work:

$ skopeo inspect -n --config docker://quay.io/podman/hello@sha256:43de9874507eaa8ffd88eac885b672b1dfc57cc583d9ad920850f97f19809f8f
{
    "created": "2024-05-26T02:17:47.007111495Z",
    "architecture": "amd64",
    "os": "linux",
    "config": {
[...]```

[nalind]

FWIW, my opinion is that it shouldn't, and the fact that manifest inspect can do that is a misfeature.

[TomSweeneyRedHat]

At the very least, though, it would be nice to change the "image not known" error to something a bit more helpful,

[arewm]

Would it make sense to provide this functionality within a dedicated sub command? My use case is that I am trying to create an image index. I want to expose some labels from the included manifests in the image index but I don't want to pull those containers locally.

[mtrmac]

FWIW, my opinion is that it shouldn't, and the fact that manifest inspect can do that is a misfeature.

I agree; at the very least the output should be clear about the origin of the data, and I feel fairly strongly that the user should be explicit about the intent; I can’t imagine use cases where it doesn’t matter to the user where the data comes from. Admittedly, on single-build VMs, the intent can often be guessed from context, but that’s not a strong reason to bundle two conceptually very different operations into one.

A local image before pushing is rather different from a remote image — it does not have the compressed representation digests refer to (i.e. “the observable data changes on push”), and, for locally-built images, it might not even have a decided manifest format.

[arewm]

Should this issue be changed to request a method within buildah to allow querying of remote images? It should support getting the raw manifest as well as the configuration (similar to --raw and --config from Skopeo) so that we can inspect both annotations and labels.

[mtrmac]

I don’t have much of an opinion on Buildah embedding this feature vs. recommending uses of Skopeo.

I see --raw as distinctly second-best, forcing users to deal with manifest formats when they might not otherwise care. But, also, short-term Skopeo is missing containers/skopeo#1283 .

[arewm]

Use of Skopeo is certainly an option for some use cases. I wanted to perform these actions in a Tekton Task step which already uses buildah and I would prefer not to use an additional step or to add an additional binary into the image.

[github-actions]

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