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
