[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH 00/23] tests/docker: start using libvirt-ci's "lcitool" for docke
From: |
Daniel P . Berrangé |
Subject: |
[PATCH 00/23] tests/docker: start using libvirt-ci's "lcitool" for dockerfiles |
Date: |
Tue, 1 Dec 2020 17:18:02 +0000 |
Currently the tests/docker/dockerfiles/*Dockerfile recipes are all hand
written by contributors. There is a common design pattern, but the set
of packages listed for installation leaves alot to be desired
- There is no consistency at all across distros
- Many potential build deps are not listed in the containers
- Some packages are not used by QEMU at all
- Adding new distros is an error prone task
The same applies to package lists for VMs, Cirrus CI / Travis CI, and
probably more.
This problem is not unique to QEMU, libvirt faced the exact same issues
and developed a program called "lcitool" which is part of the libvirt-ci
git repository to reduce the burden in this area.
https://gitlab.com/libvirt-ci/libvirt-ci/
Despite its name, this repository is not tied to libvirt, and so as well
as the 40+ libvirt git repos, it is also used by the libosinfo and
virt-viewer projects for their CI needs. The idea is that all these
projects can share the burden of libvirt-ci.
lcitool is capable of automating the installation and updating of VM
images, creation of dockerfiles and creation of standalone package
lists.
In this series I'm taking the easy step which is the generation of
dockerfiles, since that is also where the most immediate value lies
for QEMU.
The key concept in lcitool that brings a huge win in maintainability
is that there is a single file which defines a mapping between a
build pre-requisite and the native package on each targetted distro.
https://gitlab.com/berrange/libvirt-ci/-/blob/qemu/guests/lcitool/lcitool/=
ansible/vars/mappings.yml
A project merely has to have its list of pre-requisites enumerated
https://gitlab.com/berrange/libvirt-ci/-/blob/qemu/guests/lcitool/lcitool/a=
nsible/vars/projects/qemu.yml
The combination of these two files is enough to generate accurate
package lists for any supported distro. Currently supported distros
are Debian (10, sid), Ubuntu (18.04, 20.04), CentOS (7, 8, stream),
Fedora (32, 33, rawhide), OpenSUSE (151) macOS (homebrew),
FreeBSD (11, 12, current).
At the end of this series, I have dockerfiles auto-generated for QEMU
covering Ubuntu 18.04 & 20.04, CentOS 7 & 8 and Fedora 32.
lcitool is also capable of generating dockerfiles for cross-compiled
non-x86 architectures for Debian, and for mingw32/64 for Fedora. This
is driven from the very same mapping.yml file listed above, which has
attributes to indicate whether a given dependancy should be pulled from
the native or cross build target. Again this means that we have strong
guarantee of consistent deps being used between cross containers.
I have not converted cross containers in this series though, because
the way we generated cross dockerfiles is different from how QEMU does
it. lcitool will always generate fully self-contained dockerfiles, but
QEMU currently uses layered dockerfiles for cross-builds, so all cross
builds share a common intermediate container.
I could enhance lcitool to support layered containers for cross-builds,
but before doing that I wondered how strongly people are attached to
them ? If self-contained dockerfiles are acceptable I can do that more
easily.
There is also scope for auto-generating the package lists for tests/vm
and .cirrus.yml files, but I've not attempted that here. The same
general idea appies - we just call lcitool to spit out a list of native
packages for each case.
If converting tests/vm, we would need to add more distros to lcitool
mappings.yml to covert openbsd, netbsd, haiku since libvirt does not
target those distros itself.
Finally I wondered about the approach to integrating with lcitool.
I have provided a tests/docker/dockerfiles/refresh script that needs
to be invoked periodically to re-generate them. eg when adding a
new distro, or when the package lists change. I could add libvirt-ci.git
as a sub-module and provide a more seemless integration, but open to
suggestions. In libvirt*.git repos we don't bother with git submodules
for libvirt-ci.git since whomever runs it to refresh containers just
has a local checkout regardless.
Note since this is a proof of concept, the additions to libvirt-ci for
QEMU are not part of the main git repo yet, they're just in my own fork
on the "qemu" branch
https://gitlab.com/berrange/libvirt-ci/-/tree/qemu
Daniel P. Berrang=C3=A9 (23):
hw/usb/ccid: remove references to NSS
tests/docker: don't use BUILDKIT in GitLab either
tests/docker: use project specific container registries
tests/docker: use explicit docker.io registry
tests/docker: remove travis container
tests/docker: remove FEATURES env var from templates
tests/docker: fix sorting in package lists
tests/docker: fix mistakes in centos package lists
tests/docker: fix mistakes in fedora package list
tests/docker: fix mistakes in ubuntu package lists
tests/docker: remove mingw packages from Fedora
tests/docker: add script for automating container refresh
tests/docker: expand centos7 package list
tests/docker: expand centos8 package list
tests/docker: expand fedora package list
tests/docker: expand ubuntu1804 package list
tests/docker: expand ubuntu2004 package list
tests/docker: auto-generate centos7 with lcitool
tests/docker: auto-generate centos8 with lcitool
tests/docker: auto-generate fedora with lcitool
tests/docker: auto-generate ubuntu1804 with lcitool
tests/docker: auto-generate ubuntu2004 with lcitool
tests/docker: remove ubuntu container
.gitlab-ci.d/containers.yml | 5 -
.travis.yml | 14 +-
docs/ccid.txt | 15 +-
scripts/coverity-scan/coverity-scan.docker | 1 -
tests/docker/common.rc | 19 +-
tests/docker/docker.py | 4 +-
tests/docker/dockerfiles/centos7.docker | 157 +++++++++---
tests/docker/dockerfiles/centos8.docker | 153 ++++++++---
.../dockerfiles/debian-xtensa-cross.docker | 2 +-
tests/docker/dockerfiles/debian10.docker | 4 +-
tests/docker/dockerfiles/debian11.docker | 2 +-
.../dockerfiles/fedora-cris-cross.docker | 2 +-
.../dockerfiles/fedora-i386-cross.docker | 2 +-
.../dockerfiles/fedora-win32-cross.docker | 3 +-
.../dockerfiles/fedora-win64-cross.docker | 3 +-
tests/docker/dockerfiles/fedora.docker | 241 ++++++++++--------
tests/docker/dockerfiles/refresh | 67 +++++
tests/docker/dockerfiles/travis.docker | 17 --
tests/docker/dockerfiles/ubuntu.docker | 71 ------
tests/docker/dockerfiles/ubuntu1804.docker | 185 +++++++++-----
tests/docker/dockerfiles/ubuntu2004.docker | 197 +++++++++-----
tests/docker/run | 3 -
tests/docker/test-clang | 2 +-
tests/docker/test-debug | 2 +-
tests/docker/test-mingw | 3 +-
tests/docker/test-misc | 2 +-
tests/docker/test-tsan | 2 +-
tests/docker/travis | 22 --
tests/docker/travis.py | 47 ----
29 files changed, 732 insertions(+), 515 deletions(-)
create mode 100755 tests/docker/dockerfiles/refresh
delete mode 100644 tests/docker/dockerfiles/travis.docker
delete mode 100644 tests/docker/dockerfiles/ubuntu.docker
delete mode 100755 tests/docker/travis
delete mode 100755 tests/docker/travis.py
--=20
2.28.0
- [PATCH 00/23] tests/docker: start using libvirt-ci's "lcitool" for dockerfiles,
Daniel P . Berrangé <=
- [PATCH 02/23] tests/docker: don't use BUILDKIT in GitLab either, Daniel P . Berrangé, 2020/12/01
- [PATCH 01/23] hw/usb/ccid: remove references to NSS, Daniel P . Berrangé, 2020/12/01
- [PATCH 03/23] tests/docker: use project specific container registries, Daniel P . Berrangé, 2020/12/01
- [PATCH 05/23] tests/docker: remove travis container, Daniel P . Berrangé, 2020/12/01
- [PATCH 04/23] tests/docker: use explicit docker.io registry, Daniel P . Berrangé, 2020/12/01
- [PATCH 06/23] tests/docker: remove FEATURES env var from templates, Daniel P . Berrangé, 2020/12/01