On Wed, Jul 24, 2024 at 06:23:06PM GMT, Bruno Haible wrote: > Hi Simon, > > In <https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00094.html> > you wrote: > > > And while so far I've been satisfied with writing these .yml files manually, > it would be better if they all were generated by some script. The reason is: > > * Adding a new platform, or making some other change, implies a lot of > copying. > > * Applying the template to a new package requires looking at existing > CI actions. For example, C++ is used in 2-3 packages. If a new package > needs > C++, one needs to find one of the packages that already uses C++ and then > copy the relevant pieces. Which is more tedious than just writing > "use-c++: yes" > in some place. > > I'm not aware of a template system at this level. I therefore plan to go > with a (Python?) script that generates the .yml file from some specification.
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. 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 because CentOS 9 exists and CentOS 8 is more than 2 years old) - it seems like gnulib has (so far) tried to maintain a much longer window of portability and targets machines older than what libvirt-ci is willing to cater to. But even if you can't use it directly, it may give you some inspiration on writing your own tool. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
