I'm happy to pull this in and deploy it since it's causing an immediate problem. I don't love encoding these kind of rules in the code, but short-term it's fine and it's not like new architectures and happening all the time.

One thing I had considered was changing the config that maps the subvariant to the repo name to be a dictionary with the name and required_arches fields. It'll be a little bit of a hassle to transition over gracefully, but I may end up doing that at some point.

I don't like that as it means we have to duplicate the expected arches between pungi-fedora and the uploader, for every repo, forever, and always remember to update one when we update the other :/

this should really be an unusual exception thing. perhaps we could have name and allowable_missing_arches or something? but the bit I kinda liked from this design is that it allows the skip to be configured per release which seems like something we may want, and which is awkward to express in config.

I probably should have provided an example. What I mean is:

[consumer_config.container.repos]
Silverblue = "fedora-silverblue"

would become

[consumer_config.container.repos.Silverblue]
name = "fedora-silverblue"
required_arches = ["s390x"]  # Optional field, if not present all arches are required. Here we won't push an update unless all our s390x users get it.
[consumer_config.container.repos.Container_Toolbox]
...

I was also thinking having it as a dictionary would be nice to allow you to configure some of the annotations we should be applying, like a link to the documentation for a particular image.

I'm fine for it being a "we're okay if this particular arch isn't there" too.