Re: [libvirt PATCH 4/4] gitlab-ci: Introduce a new test 'integration' pipeline stage
...
> > 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