[libvirt-jenkins-ci PATCH v2 5/6] guests: Introduce the new 'gitlab' flavor

[Andrea Bolognani]

On Wed, 2020-04-08 at 15:56 +0200, Erik Skultety wrote:
> On Wed, Apr 08, 2020 at 03:21:00PM +0200, Andrea Bolognani wrote:
> > I guess you could drop the image element and replace it with
> > 
> >   tags:
> >     - fedora-31
> 
> ^This is what I had in mind
> 
> > but then you'd either have to duplicate the job definition, or to
> > only have the new one which then would not work for forks and merge
> > requests, so that makes it less interesting.
> 
> We'll have to duplicate it for FreeBSD anyway, so I don't understand why should
> do it differently for other VM distros.

We will not duplicate it, because there is no existing container
based build for FreeBSD: the FreeBSD builds can, by definition, only
happen inside VMs.

> > I don't understand what you're trying to say here at all, sorry.
> 
> What I meant is that I don't see much value to run the builds in VMs since we
> have a bunch of images ready where we can already execute the builds

Totally agree with you up until this point: this is exactly what I
was trying to convey.

> so it's
> basically only about having resources to spawn the containers and that's where
> OpenShift comes in.

I still don't understand how OpenShift is part of the picture. I have
probably either missed or forgotten something O:-)

> I understand you reminding me that private runners cannot be used to run on
> merge requests (and forks for obvious reasons), but the same applies to VMs
> we're discussing in this thread. So, I wouldn't focus primarily on running the
> builds there is what I'm saying.

I think we're kind of talking past each other at this point :)

To reiterate/clarify: I'm perfectly okay with using Linux VMs for
integration testing only and leaving builds to shared runner and
FreeBSD VMs. I don't think we should use Linux VMs for builds unless
we use the docker executor for them, but then again I don't think we
really need to use Linux VMs for builds in the first place.

-- 
Andrea Bolognani / Red Hat / Virtualization