Bruno Haible <br...@clisp.org> writes: > gnulib-tool is used is many CI jobs. Just adding 'python3' to the > prerequisites of such a job makes it run faster. Here are the execution > times for a single run, before and after adding 'python3', for those > CIs that I maintain or co-maintain. In minutes and seconds. > > Before After > > https://gitlab.com/gnulib/gnulib-ci/-/pipelines 30: 11: > https://gitlab.com/gnu-gettext/ci-distcheck/-/pipelines 36: 32: > https://gitlab.com/gnu-poke/ci-distcheck/-/pipelines 18:40 18:24 > https://gitlab.com/gnu-libunistring/ci-distcheck/-/pipelines 11:25 09:16 > https://gitlab.com/gnu-diffutils/ci-distcheck/-/pipelines 07:21 06:27 > https://gitlab.com/gnu-grep/ci-distcheck/-/pipelines 06:51 06:08 > https://gitlab.com/gnu-m4/ci-distcheck/-/pipelines 06:46 05:44 > https://gitlab.com/gnu-sed/ci-distcheck/-/pipelines 05:28 04:39 > https://gitlab.com/gnu-gzip/ci-distcheck/-/pipelines 04:16 03:58 > https://gitlab.com/gnu-libffcall/ci-distcheck/-/pipelines 01:50 01:42 > https://gitlab.com/gnu-libsigsegv/ci-distcheck/-/pipelines 00:45 00:42
These are useful pipelines with basic build testing! I help on a bunch of others below, to get broader OS/architecture-compatibility testing. https://gitlab.com/gsasl/inetutils/-/pipelines https://gitlab.com/gsasl/gsasl/-/pipelines https://gitlab.com/gsasl/shishi/-/pipelines https://gitlab.com/gsasl/gss/-/pipelines https://gitlab.com/libidn/libidn2/-/pipelines https://gitlab.com/libidn/libidn/-/pipelines https://gitlab.com/gnutls/libtasn1/-/pipelines I think the pattern of having the .gitlab-ci.yml outside of the core Savannah project is a good one for those GNU projects who are not embracing the GitLab platform. Then GitLab-related stuff stays on the GitLab platform and doesn't invade the core project. Would it make sense to collaborate on re-usable GitLab CI/CD pipeline definitions in a single GitLab project? Then we can apply that group for free CI/CD minutes and get testing on macOS/Windows too. I have a shared GitLab runner for native arm64 and ppc64el building, and have wanted to setup NetBSD/OpenBSD/FreeBSD/etc GitLab runners too. Adding runners to a group is easy, adding it to multiple groups require some manual work and added resources on the runner. How about using https://gitlab.com/gnulib/ as a playground for these ideas? Then we can add sub-projects there for pipeline definitions, and Savannah mirrors of other projects too. If you can add 'jas' as maintainer of the 'gnulib' group on GitLab I could add one project to start work on writing re-usable pipeline definitions, and one example project maybe for GNU InetUtils that would use these new re-usable pipeline components to provide a CI/CD pipeline definition file. I could add some arm64/ppc64el builds of gnulib too. /Simon
signature.asc
Description: PGP signature
