Re: Adding CI to our tree - Mailing list pgsql-hackers

From Matthias van de Meent
Subject Re: Adding CI to our tree
Date
Msg-id CAEze2Wh2q7pFYRZiOabscG-rmFcjUA1AU_bCFpA6gogbf6Z3fw@mail.gmail.com
Whole thread Raw
In response to Re: Adding CI to our tree  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Adding CI to our tree
Re: Adding CI to our tree
List pgsql-hackers
On Sat, 2 Oct 2021 at 17:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andres Freund <andres@anarazel.de> writes:
> > It's not like this forces you to use cirrus or anything. For people that don't
> > want to use CI, It'll make cfbot a bit more effective (because people can
> > adjust what it tests as appropriate for $patch), but that's it.

I don't disagree on that part, but I fail to see what makes the
situations of an unused CI config file in the tree and an unused
`/.idea/` or `/.vs/` specifier in the .gitignore [0][1] distinct
enough for it to be resolved differently. Both are quality-of-life
additions for those that use that tool, while non-users of that tool
can ignore those configuration entries.

> Yeah.  I cannot see any reason to object to Andres' 0002 patch: you can
> just ignore those files if you don't want to use cirrus.  It does set a
> precedent that we'd also accept infrastructure for other CI systems,
> but as long as they're similarly noninvasive, why not?  (Maybe there
> needs to be one more directory level though, ie ci/cirrus/whatever.
> I don't want to end up with one toplevel directory per CI platform.)

With the provided arguments I won't object to the addition of these
config files, but I would appreciate it if a clear policy could be
provided on the inclusion of configurations for external tools that
are not expected to be used by all users of the repository, such as
CI, editors and IDEs.

Kind regards,

Matthias van de Meent

[0]
https://www.postgresql.org/message-id/flat/OS3PR01MB71593D78DD857C2BBA9FB824F2A69%40OS3PR01MB7159.jpnprd01.prod.outlook.com
[1] https://www.postgresql.org/message-id/flat/15BFD11D-5D72-46B2-BDB1-2DF4E049C13D%40me.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Fix memory corruption in pg_shdepend.c
Next
From: "David G. Johnston"
Date:
Subject: Re: [PATCH] Fix memory corruption in pg_shdepend.c