[libvirt PATCH 4/4] gitlab-ci: Introduce a new test 'integration' pipeline stage
Erik Skultety
eskultet at redhat.com
Wed Mar 2 16:22:07 UTC 2022
...
> > > 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
More information about the libvir-list
mailing list