...
I could easily see the instance of libvirt-gitlab-executor running on hardware owned and operated by Red Hat returning a failure if a job submitted to it comes with DISTRO=debian-11.
libvirt-gitlab-executor is supposed to be system owner agnostic, I'd even like to make the project part of the libvirt gitlab namespace umbrella so that anyone can use it to prepare their machine to be plugged into and used for libvirt upstream integration testing.
I absolutely agree and it was always my understanding that the project living under your personal account was only a temporary measure.
Therefore, I don't think the project is the right place for such checks, those should IMO live solely in the gitlab-ci.yml configuration.
To be clear, I didn't mean that the software itself should contain hardcoded limits on what jobs it will process, but rather that it would make sense for it to offer a configuration setting along the lines of
accept_distros: - "alpine-*" - "debian-*"
It's surely up for a discussion, I haven't made any hard decisions wrt where should the project be headed, right now it's very simple, let's see :).
that can be used by the local sysadmin to define such a policy.
true, but I suppose from upstream's perspective it can already be handled using gitlab tags only, so it feels redundant to handle the same on multiple places.
I guess this is already sort of already implicitly implemented due to the fact that a job will fail if the corresponding VM template does not exist...
Yes, it'll throw an error, possibly an ugly exception (I hope not) when this happens. Erik