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

[Erik Skultety]

On Wed, Apr 08, 2020 at 03:21:00PM +0200, Andrea Bolognani wrote:
> On Wed, 2020-04-08 at 12:28 +0200, Erik Skultety wrote:
> > On Wed, Apr 08, 2020 at 12:05:11PM +0200, Andrea Bolognani wrote:
> > > You didn't answer in the other thread, so I'll ask again here: is the
> > > idea that we're going to use only the FreeBSD runners to supplement
> > > the shared runners for the existing unit tests, and all Linux runners
> > > are only going to be used for integration tests later on, hence why
> > > we need to use the shell executor rather than the docker executor?
> >
> > Why not both? We can always extend the capacity with VM builders, although it's
> > true that functional tests was what I had in mind originally (+the FreeBSD
> > exception like you already mentioned). Either way, I don't understand why we
> > should force usage of the docker executor for the VMs which we can use for
> > builds.  The way I'm looking at the setup is: container setup vs VM setup, with
> > both being consistent in their own respective category, IOW, why should the
> > setup of the VM in terms of the gitlab-runner be different when running
> > functional tests vs builds? So, I'd like to stay with the shell executor on VMs
> > in all cases and not fragment the setup even further.
>
> Because all the builds that currently exist are defined in terms of
> containers, so when you have something like
>
>   x86-fedora-31:
>     script:
>       ...
>     image: quay.io/libvirt/buildenv-libvirt-fedora-31:latest
>
> you cannot just run the same job on a worker that is configured to
> use the shell executor.
>
> 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.

>
> > Furthermore, with the OpenShift infra we got, I see very little to no value in
> > using the VMs to extend our build capacity.
>
> 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 so it's
basically only about having resources to spawn the containers and that's where
OpenShift comes in.
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.

--
Erik Skultety