Hi Simon, In <https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00094.html> you wrote:
> >> I forgot to mention: the pattern to provide re-usable GitLab CI/CD > >> definitions that I'm inspired by is Debian's pipeline project: > >> > >> https://salsa.debian.org/salsa-ci-team/pipeline/ > >> > >> It is easy to setup a new project to use their reusable pipeline -- just > >> add the CI/CD configuration file setting pointing to their job file -- > >> and gives a broad configurable and tweakable pipeline. > > > > Sorry if this sounds negative, but > > > > - So far, I've loved to adapt my CIs as needed. For example, one package > > has a number of --with options, so my CI first builds without these > > --with options, then installs the extra Debian packages and builds a > > second time with these --with options. I don't think that any > > pipeline framework can give me this possibility without causing > > massive hurdles. > > > > - With such frameworks, documentation is key. > > Yes, any reusable system will need to support additional system packages > and ./configure flags and so on. > > >> I'm thinking we could do the same but for any project using gnulib. > >> Within some reasonable limit and assumptions, but the majority of > >> projects mentioned already are similar enough for this to be possible > >> relatively easily. > >> > >> I'm thinking it should be sufficient to add gnu-ci.yml@gnulib/pipeline > >> (or similar) as a CI/CD configuration file setting to achieve this. > > > > It's quite possible that with this approach, you can bring more GNU packages > > into the "we have CI" camp. > > > > I wouldn't like to switch to such a framework, though, because I'm already > > too much of an expert in GitLab CI. > > Right -- the key to this working well is that no switch should be > necessary. Written properly, you add one 'include' to your existing job > definition file and that enable opt-in functionality. By now, I've completed a "many platforms" CI for several GNU packages: https://github.com/gnu-gnulib/ci-testdir-check/actions https://github.com/gnu-diffutils/ci-check/actions https://github.com/gnu-gettext/ci-check/actions https://github.com/gnu-libsigsegv/ci-check/actions https://github.com/gnu-libunistring/ci-check/actions https://github.com/gnu-m4/ci-check/actions https://github.com/gnu-sed/ci-check/actions 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. Bruno
