Re: [PATCH v2 2/2] GitLab Gating CI: initial set of jobs, documentation and scripts

[Gerd Hoffmann]

  Hi,

> > IOW, a RHEL-8 aarch64 host, running docker for ubuntu18.04, fedora30
> > etc.
> 
> I've come across so many caveats and corner cases that having the
> lowest common denominator proved to be the smart and sane thing to do.
> For instance, building on the example you gave, running a RHEL 8
> aarch64 host is a NO GO Today because RHEL 8 doesn't ship with docker
> and the gitlab runner needs to be taught to talk to, say, Podman.

podman got support for the docker daemon api (v2.0 I think), so 
this should be possible soon, without changing gitlab runner.

Also there is a kubernetes runner so you can run the thing in pretty
much any cluster.  k3s.io seems to be the easiest way to boot up a small
kubernetes cluster on pretty much any linux system.  Works on aarch64
too.  Didn't try (yet) to run the gitlab runner there.

> Finally, it's going to be very important for some organizations to
> run tests outside of container environments.  For instance, Red Hat
> needs to run QEMU+KVM tests on bare metal and on VMs, in addition
> to containers.

Also for *BSD testing.
For setting up VM images we should use tests/vm.

> Like I explained before, containers-only won't cut it.  So, we need
> tooling that is environment agnostic.  So far, ansible playbooks seem
> to be a reasonable solution.  But duplicating information bothers me
> as much as it seems to bother you, so we need to engage in common
> tooling that is capable of generating those container environments,
> but not be limited to it.  One example of a tool that seems to be
> a good candidate is "Libvirt's" lcitool.

What is wrong with the docker files we have?

It is a good idea anyway to use the same images for local test builds
and CI.  Makes it easier to reproduce CI failures locally.

take care,
  Gerd