Hi Eric,
> Have you looked at libvirt-ci[1]? Several projects (among others:
> libvirt, qemu, libnbd) use this for templating CI that works across
> both gitlab and github (preferring to run CI under gitlab as it is
> less invasive of freedoms, but taking advantage of github's access to
> MacOS testing).
>
> [1] https://gitlab.com/libvirt/libvirt-ci/
>
> Among other things, the lcitool program inside that package makes it
> possible to write a fairly stream-lined description of general package
> names that are required, then looks up in a database the correct
> spellings of how to pull in those packages across various distros
> present in CI systems, so that I end up modifying only one .yml file
> instead of one per platform when I need to tweak the CI setup to track
> a change in various distro bleeding edge.
Thanks a lot for this pointer!
It confirms my (previously vague) intentions to
* use YAML as configuration language,
* use Python as implementation language,
* have a database of package names per distro type, such as
readline:
apk: readline-dev
deb: libreadline-dev
rpm: readline-devel
> One potential drawback: libvirt-ci intentionally declares that it will
> not support stable enterprise distros more than 2 years beyond
> introduction if a newer release is available (that is, CentOS 8 is no
> longer a viable libvirt-ci target
Surely, gnulib and many GNU packages have a wider list of targets.
But the principles are the same.
Bruno
