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
