Idea: Add a new check that a Docker image is multi-arch

[martin-g]

Hi,

What

I'd like to propose adding a new check - Docker images published by monitored projects must be multi-arch! By multi-arch I think that amd64 and arm64 should be mandatory! ppc64le, s390x and other architectures are nice to have!

How

The (optional) fully qualified name of Docker image(s) will be added to the YAML files at https://github.com/cncf/clomonitor/blob/main/data/ for the projects which publish such.

The new check may use DockerHub REST APIs to get the manifest. If the REST API cannot be used for some reason (e.g. the project publishes at an alternative Docker registry) then the new check may use docker-inspect (or podman-inspect) to list the supported architectures, but this requires docker pulling the image locally!

Why

Many projects still provide amd64 (x86_64) only images. But ARM64 is more and more used both for server deployments (most cloud providers provide ARM64 VMs) and for development (Apple M1/M2/M3 and some Linux laptops).

---

I understand that most of the other available checks work with the contents of the (Git) repository, e.g. check that a specific content is provided in a specific file. The proposed new check would work with "an external resource" (the Docker image/manifest), so it is similar to the Scoreboard based checks, more specifically to the signed_release check.

What do you think ? I am willing to work on this new check if the community approves the idea !

[tegioz]

Hi @martin-g 👋

Usually we aim for checks that are generic enough in the sense that they can apply to most projects. IMHO this is a very specific requirement that would only apply to a subset of them. Many may not even be publishing container images at all. So asking them to go even further and publish images for multiple architectures may be a bit too much.

Regarding the "how": keeping track of the images published by each project in the CLOMonitor data files would require quite a bit of effort by all projects publishing images periodically, plus some more on our side to handle that flow of PRs. I highlighted periodically because we'd need the corresponding images tags to be always up to date as new versions are released to be able to check them. And TBH I don't think we should ask projects to invest time on something like that.

Independently of this check, it'd be great if those images were defined somewhere in a standardized way though. We've faced a similar problem in Artifact Hub as there isn't yet an official mechanism in Helm to define the images a chart uses. So in the meantime we are detecting them by doing a dry-run of the chart installation and extracting them with some regular expressions (unfortunately it isn't always accurate). Alternatively we allow users to define them as annotations in the chart (sorry, this went a bit off-topic 😅).

[martin-g]

Hi @tegioz ! Thank you for the quick response!

The new check should be used only for the projects which declare the new optional setting in the YAML file:

The (optional) fully qualified name of Docker image(s) will be added to the YAML files at https://github.com/cncf/clomonitor/blob/main/data/ for the projects which publish such.

If a project does not publish any Docker image then there is nothing to check.

[tegioz]

No worries!

But that's not how checks work in CLOMonitor :)

When a new check is added, it applies to all projects, not just the ones which opt-in (precisely, to all repositories using a given check set). This allows us to score them properly, and generate stats and reports about how each project is doing.

It's possible to declare exemptions, but doing that automatically for those not providing their images would kind of defy the point of this check.

Please note that having those images defined in the CLOMonitor data files is not an option anyway for the reasons I mentioned before.

Hope this helps :)

[tegioz]

because we'd need the corresponding images tags to be always up to date as new versions are released to be able to check them

It'd be possible to rely on the latest tag as well, but the list would still need to be populated and maintained to be up to date in terms of images added/removed (i.e. new components), registry changes, images variants, etc. There are already hundreds of projects in CLOMonitor, with more to come. That kind of information should probably be hosted somewhere else, not in CLOMonitor.

But in any case, I think this is a very specific requirement that won't apply to many projects, so not sure if this fits well in CLOMonitor.