Note that what the current script for containers does is the "hybrid manifest" approach, but I think that's more or less by chance, I'm not sure it was designed that way. The current script finds the most recent successful Koji task for each type and arch of container and builds a manifest out of those. I think it's just assuming the most recent successful task will be the one from the most recent compose, but as it happens, if it isn't, it will naturally "fall back" to whatever the previous successful task of the same type for the same release was.

What's happening here isn't immediately obvious to me.

I initially thought it was to work around buildah not being able to list a remote manifest, but it seems happy to do that:

surface5 in ~
❯ buildah manifest inspect quay.io/fedora/fedora:40
{
    "schemaVersion": 2,
    "mediaType": "application/vnd.oci.image.index.v1+json",
    "manifests": [
        {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:99563158175e056de38d23bf074ea3e91861971c0a73e7664faae535af4ed9fa",
            "size": 504,
            "platform": {
                "architecture": "arm64",
                "os": "linux"
            }
        },
        {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:89b870b45e9e410e1a018ee777b50dc2cc2a2d8896414e34b5f1a51b4724fcbf",
            "size": 504,
            "platform": {
                "architecture": "ppc64le",
                "os": "linux"
            }
        },
        {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:70f7e514851a0836d94e9ef644d0abffa751f71e215520ca4fce32ca9b78e82d",
            "size": 504,
            "platform": {
                "architecture": "s390x",
                "os": "linux"
            }
        },
        {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:1415ea89e284dfd26bcc58c046819a46305215050a8bb48f8ea45ed50a55ffe6",
            "size": 504,
            "platform": {
                "architecture": "amd64",
                "os": "linux"
            }
        }
    ]
}

it was based on advice in https://pagure.io/cloud-image-uploader/issue/17#comment-913921 - I thought the implication of that comment was that doing so was the only way to get the contents of a remote manifest. if we can just buildah manifest inspect it directly, that is definitely much easier, I will test that a bit and switch to it if so.

well, I think we can do that, but this will need rebasing on https://pagure.io/cloud-image-uploader/pull-request/22 , so let's review/merge that first.

OK, rebased on the other recent changes, and simplified how we inspect the current manifest.

When a new architecture gets added this will crash with a KeyError. An alternative could be to just default to darch, but there's no guarantee we'll line up with the manifest name for an architecture so maybe failing loudly is fine?

Yeah, on the whole, I think I'd rather fail. If we do the fallback-to-darch thing, then if a new arch gets added whose manifest name is different, we would then fail to publish every compose, logging an error, till someone noticed...I'm not sure that's better?

good catch, though!

Cool, sounds fine to me.

awesome, thanks! so I guess you can rebase your messaging PR now?