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@xxxxxx/ [2] https://docs.gitlab.com/ee/ci/index.html#the-gitlab-ciyml-file > > Patrick >
