On Thu, 2020-07-09 at 11:30 +0100, Daniel P. Berrangé wrote: > On Wed, Jul 08, 2020 at 10:46:57PM -0400, Cleber Rosa wrote: > > +- name: Installation of basic packages to build QEMU > > + hosts: all > > + vars_files: > > + - vars.yml > > + tasks: > > + - name: Install basic packages to build QEMU on Ubuntu 18.04/20.04 > > + apt: > > + update_cache: yes > > + # This matches the packages on > > tests/docker/Dockerfiles/ubuntu1804.docker > > I'd be inclined to actually use docker on the custom runners. > > eg. instead of having separate physical machines or VMs for each > (distro, arch) pair, have a single host distro for the arch. Then > use docker to provide the build environment against each distro. > > IOW, a RHEL-8 aarch64 host, running docker for ubuntu18.04, fedora30 > etc. > > That way we don't end up duplicating all these packages, and instead > can use tests/docker/Dockerfiles/ubuntu1804.docker. This ensures > that if a user needs to reproduce a build failure on their own local > aarch64 machine, they can run docker and get the exact same build > architecture. > > It also has the benefit that we don't need to worry about how to > setup gitlab runners for every distro we care about. We only need to > do gitlab runner for the standard host distro, which spawns a pristine > throwaway docker env. > > I appreciate this is a big change from what you've done in this patch > though, so don't consider this comment a blocker for initial merge. > I think we should do this as the long term strategy though. Essentially > for Linux builds, everything should always be container based.
Agreed. You should be able to set up a fairly minimal environment, which consists of Docker, gitlab-runner and not much else, using a long-term supported distro such as CentOS and then just schedule whatever container build on it. No need to provision a new machine every time a new Fedora release comes out, just create a container image for it and add it to the mix. Additionally, the gitlab-runner Docker executor provides more isolation than the shell executor, so running untrusted builds becomes a more reasonable proposition - this is how the shared runners on gitlab.com work - and you don't have to worry about your jobs cleaning up properly after themselves nearly as much. -- Andrea Bolognani / Red Hat / Virtualization