Re: [libvirt-jenkins-ci PATCH v2 5/6] guests: Introduce the new 'gitlab' flavor
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