Re: [libvirt-jenkins-ci PATCH v2 5/6] guests: Introduce the new 'gitlab' flavor
On Wed, Apr 08, 2020 at 12:05:11PM +0200, Andrea Bolognani wrote:
On Tue, 2020-04-07 at 13:31 +0200, Erik Skultety wrote:
> +- name: Register the gitlab-runner agent
> + become: true
> + become_user: gitlab
> + shell: '/home/gitlab/bin/gitlab-runner register --non-interactive --config {{
gitlab_runner_config_path }} --registration-token {{ gitlab_runner_secret }} --url {{
gitlab_url }} --executor shell --tag-list {{ inventory_hostname }}'
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.
Furthermore, with the OpenShift infra we got, I see very little to no value in
using the VMs to extend our build capacity.
Additional nit: instead of using {{ inventory_hostname }} as tag, we
can have a nicer tag by using {{ os_name|lower }}-{{ os_version }}.
Sure, I don't mind that change.
It would also be a good idea to quote all command arguments.
Will do.
--
Erik Skultety