Re: [PATCH] Add GitLab CI to PostgreSQL

On Wed, Jul 5, 2023 at 6:22 AM Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 2023-07-04 Tu 19:44, Newhouse, Robin wrote:
>
> Hello!
>
>
>
> I propose the attached patch to be applied on the 'master' branch
>
> of PostgreSQL to add GitLab CI automation alongside Cirrus CI in the PostgreSQL repository.
>
>
>
> It is not intended to be a replacement for Cirrus CI, but simply suggestion for the
>
> PostgreSQL project to host centrally a Gitlab CI definition for those who prefer to use
>
> it while developing/testing PostgreSQL.
>
>
>
> The intent is to facilitate collaboration among GitLab users, promote standardization
>
> and consistency, and ultimately, improve testing and code quality.
>
>
> This seems very RedHat-centric, which I'm not sure is a good idea.

A few years ago, a proposal to use CentOS may not have been a bad
proposal. But since Redhat changed CentOS to be an upstream distro
(rather than a rebuild of RHEL), I do see a reason to consider RHEL as
a candidate in our CI.

I think the idea of a pre-buildfarm CI is to enable contributors catch
problems before they're merged, or even before proposed as a patch to
the community. So if our CI includes support for a prominent Linux
distro, I think it's worth it, to provide coverage for the large
ecosystem that's based on RHEL and its derivatives.

Would using RockyLinux assuage these concerns? Perhaps, it would.

> If we're going to do this then arguably we should also be supporting GitHub Actions and who knows what other CI
frameworks.There is a case for us special casing Cirrus CI because it's used for the cfbot. 

We've already lost that battle by supporting one
commercial/non-community provider. From Anrdres' email [1]:

> An obvious criticism of the effort to put CI runner infrastructure into core
> is that they are effectively all proprietary technology, and that we should be
> hesistant to depend too much on one of them. I think that's a valid
> concern. However, once one CI integration is done, a good chunk (but not all!)
> the work is transferrable to another CI solution, which I do think reduces the
> dependency sufficiently.

So it seems that supporting more than one CI was always on the cards.
Cirrus was chosen for its advantages that Andres mentions in the
email, but also for the reason that cfbot had chosen Cirrus. I can
imagine if cfbot was developed against some other CI, it's very likely
that we'd be using that other CI instead of Cirrus.

[1]: https://www.postgresql.org/message-id/20211001222752.wrz7erzh4cajvgp6%40alap3.anarazel.de

Best regards,
Gurjeet
http://Gurje.et