[libvirt PATCH 4/4] gitlab-ci: Introduce a new test 'integration' pipeline stage

[Erik Skultety]

...

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