Re: [PATCH v4 3/4] Jobs based on custom runners: docs and gitlab-runner setup playbook

[Andrea Bolognani <abologna@redhat.com>]

On Tue, 2020-10-20 at 09:29 +0100, Daniel P. Berrangé wrote:
> I think the obvious and easy place is start using lcitool is for the
> tests/docker/dockerfiles/*.  All that's required is to add mappings
> to lcitool for the various deps that QEMU has which libvirt does not
> already have. Then we should be able to start auto-generating the
> dockerfiles without too much difficulty. This will be a significant
> step forward because it will help us keep te package lists in sync
> across all the dockerfiles which is a major fail in QEMU right now.

I took a quick look at the contents of those dockerfiles and while I
agree that it's the obvious place to start, I'm not sure I would say
that generating them using lcitool is going to be easy :)

Basically there seem to be a number of assumptions both in lcitool
and in the QEMU dockerfiles, and getting the two to agree on those
will require quite some work from what I can tell.

But again, I agree it's something that should be worked on.

> Dealing with tests/vm replacement or these ansible recipes is likely
> to be a significantly more challenging proposition. Perhaps we can
> again start by just automating creation of the package lists that
> the tests/vm and ansibile recipes need, as again those are all
> inconsistent.

Perhaps 'lcitool variables' could be of use here.

-- 
Andrea Bolognani / Red Hat / Virtualization