Re: [PATCH] Add GitLab CI to PostgreSQL

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: "Newhouse, Robin" <robinnew(at)amazon(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Kekalainen, Otto" <ottoke(at)amazon(dot)com>
Subject: Re: [PATCH] Add GitLab CI to PostgreSQL
Date: 2023-07-06 11:32:14
Message-ID: 98afc65f-ebb2-a20b-9adf-de533e5d261f@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2023-07-05 We 11:58, Matthias van de Meent wrote:
> On Wed, 5 Jul 2023 at 15:22, Andrew Dunstan<andrew(at)dunslane(dot)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.
> Can you configure GitLab to use a .gitlab-ci.yml file that is not in
> the root directory?
>
>>> 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. Also, shouldn't at least some of these recipes call dnf and dnf-builddep instead of yum and yum-build-dep?
> I don't think it's bad to add an automated test suite for redhat-based images?

I didn't suggest it wasn't just that the coverage should be broader.

>
>> 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.
> I think there's a good case for _not_ using Cirrus CI, namely that the
> license may be prohibitive, self-management of the build system
> (storage of artifacts, UI, database) is missing for Cirrus CI, and it
> also seems to be unable to run automated CI on repositories that
> aren't hosted on Github.
> I think these are good arguments for adding a GitLab CI configuration.
>
> Unless the cfbot is entirely under management of the PostgreSQL
> project (which it doesn't appear to be, as far as I know the URL is
> still cfbot.cputube.org indicating some amount of external control)
> the only special casing for Cirrus CI within the project seems to be
> "people have experience with this tool", which is good, but not
> exclusive to Cirrus CI - clearly there are also people here who have
> experience with (or are interested in) maintaining GitLab CI
> configurations.
>

I would not assume too much from the URL. The PostgreSQL BuildFarm
operated for many years with a URL that was not under postgresql.org. I
assume the URL is partly a function of the fact that Thomas started the
cfbot as a bit of a skunkworks project. However it's run, the fact is
that the project relies to some extent on it.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2023-07-06 11:40:31 HOT readme missing documentation on summarizing index handling
Previous Message Mikhail Gribkov 2023-07-06 11:31:00 Re: Permute underscore separated components of columns before fuzzy matching