Re: [PATCH v4 0/8] ci: add GitLab CI definition

[Victoria Dye <vdye@github.com>]

Patrick Steinhardt wrote:
> Hi,
> 
> this is the fourth version of my patch series that introduces support
> for GitLab CI.
> 
> Changes compared to v3:
> 
>     - Stopped using nproc(1) to figure out the number of builds jobs for
>       GitHub Actions and Azure Pipelines. Instead, we now continue to
>       use the hardcoded 10 jobs there, whereas on GitLab CI we now use
>       nproc. We can adapt GitHub/Azure at a later point as required, but
>       I don't feel comfortable doing changes there.
> 
>     - Improved the linux-musl job. Namely, we now also install all
>       required Apache modules, which makes the Apache-based test setup
>       work. There is a packaging issue with the WebDAV module though, so
>       we now skip tests that depend on it on Alpine Linux.
> 
> I still didn't move `.gitlab-ci.yml` to `contrib/`. As Taylor argued
> (and I don't disagree), moving it to `contrib/` would convey the spirit
> that this is _not_ an authoritative CI pipeline setup. But I wanted to
> hear other opinions first before moving it into `contrib/`.

I've read through some of the earlier discussion on this (as well as your
original cover letter [1]), so I'll throw in my 2c.

The majority of the changes in this patch series aren't conditioned on
anything that says "gitlab", they just improve the flexibility of our CI
scripts. I personally didn't notice anything too cumbersome added in the
series, so I'm happy with all of that (essentially, patches 1-7 & parts of
8).

As for adding the GitLab-specific stuff, I'm not opposed to having it in the
main tree. For one, there doesn't seem to be a clean way to "move it into
`contrib/`" - '.gitlab-ci.yml' must be at the root of the project [2], and
moving the $GITLAB_CI conditions out of the 'ci/*.sh' files into dedicated
scripts would likely result in a lot of duplicated code (which doesn't solve
the maintenance burden issue this series intends to address).

More generally, there are lots of open source projects that include CI
configurations across different forges, _especially_ those that are
officially mirrored across a bunch of them. As long as there are
contributors with a vested interest in keeping the GitLab CI definition
stable (and your cover letter indicates that there are), and the GitLab
stuff doesn't negatively impact any other CI configurations, I think it
warrants the same treatment as e.g. GitHub CI.

[1] https://lore.kernel.org/git/cover.1698305961.git.ps@pks.im/
[2] https://docs.gitlab.com/ee/ci/index.html#the-gitlab-ciyml-file

> 
> Patrick
>