Re: continuous integrations

[Bruno Haible]

Hi Simon,

> These are useful pipelines with basic build testing!

My main use of these CI pipelines are to
  - find regressions caused by commits in the respective packages,
  - find regressions caused by gnulib (despite upstream having gnulib
    as a git submodule),
  - create snapshot tarballs for GNU m4.

> 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.

Yes, that's one reason I put the CI outside the main repository. The
other reasons are:
  - CIs will come and go over time. Whereas the source code is meant to
    be stable for > 20 years.
  - Maintaining CIs is a different business than developing. It can be
    handled by different persons, with different skills.
  - I had problems creating a git repository's mirror from Savannah at
    GitLab. If we can't have a GNU package's mirror at GitLab, and of
    course don't want to move the main repository away from Savannah,
    that was the only option.
  - There is also the possibility of having CIs on other clouds, such as
    GitHub, Travis, etc. This is simpler if there is no mirroring
    in-between.

> 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.

I am currently experimenting with CI on GitHub, with the immediate goal
of testing Gnulib's testdirs on various macOS versions. (The macOS machine
in the compilefarm is not up-to-date.) This should also give FreeBSD and
Solaris 11 testing.

> Then we can apply that group for free CI/CD minutes

What do you mean by that? I've found GitLab's limit of 400 minutes per
month and top-level group limiting, and see that GitHub does not have such
a limit.

> 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.

On GitLab, the 400 minutes limit is per top-level group. Therefore, it's
better if, for each GNU package, we have a separate top-level group.

> If you can add 'jas' as
> maintainer of the 'gnulib' group on GitLab

Done.

> 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.

The usefulness of this step depends on how much it would reduce the
frequency of the x86_64 runs (which currently are at 1/week). Most
parts of Gnulib are not arch-specific; therefore I think the minutes
are better invested in testing Alpine Linux, FreeBSD, OpenBSD, than
arm64/ppc64el.

Bruno