[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnulib-tool.py speeds up continuous integrations
From: |
Simon Josefsson |
Subject: |
Re: gnulib-tool.py speeds up continuous integrations |
Date: |
Mon, 06 May 2024 17:49:07 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Bruno Haible <bruno@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