... > > > 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
