Bruno Haible 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:4018:24
> https://gitlab.com/gnu-libunistring/ci-distcheck/-/pipelines 11:2509:16
> https://gitlab.com/gnu-diffutils/ci-distcheck/-/pipelines 07:2106:27
> https://gitlab.com/gnu-grep/ci-distcheck/-/pipelines 06:5106:08
> https://gitlab.com/gnu-m4/ci-distcheck/-/pipelines06:4605:44
> https://gitlab.com/gnu-sed/ci-distcheck/-/pipelines 05:2804:39
> https://gitlab.com/gnu-gzip/ci-distcheck/-/pipelines 04:1603:58
> https://gitlab.com/gnu-libffcall/ci-distcheck/-/pipelines 01:5001:42
> https://gitlab.com/gnu-libsigsegv/ci-distcheck/-/pipelines00:4500: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
