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

From Andrew Dunstan
Subject Re: Adding CI to our tree
Date
Msg-id 87a81b91-87bf-c0bc-7e4f-06dffadcf737@dunslane.net
Whole thread Raw
In response to Re: Adding CI to our tree  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Adding CI to our tree
List pgsql-hackers
On 1/14/22 18:54, Justin Pryzby wrote:
> On Fri, Jan 14, 2022 at 03:34:11PM -0800, Andres Freund wrote:
>> Hi,
>>
>> On 2022-01-13 15:27:40 -0500, Andrew Dunstan wrote:
>>> I can probably adjust to whatever we decide to do. But I think we're
>>> really just tinkering at the edges here. What I think we really need is
>>> the moral equivalent of `make check-world` in one invocation of
>>> vcregress.pl.
>> I agree strongly that we need that. But I think a good chunk of Justin's
>> changes are actually required to get there?
>>
>> Specifically, unless we want lots of duplicated logic in vcregress.pl, we
>> need to make vcregress know how to run NO_INSTALLCHECK test. The option added
>> was just so the buildfarm doesn't start to run tests multiple times...
> The main reason I made the INSTALLCHECK runs conditional (they only run if a
> new option is specified) is because of these comments:
>
> | # Disabled because these tests require "shared_preload_libraries=pg_stat_statements",
> | # which typical installcheck users do not have (e.g. buildfarm clients).
> | NO_INSTALLCHECK = 1
>
> Also, I saw that you saw that Thomas discovered/pointed out that a bunch of TAP
> tests aren't being run by CI.   I think vcregress should have an "alltap"
> target that runs everything like glob("**/t/").  CI would use that instead of
> the existing ssl, auth, subscription, recovery, and bin targets.  The buildfarm
> could switch to that after it's been published.
>
> https://www.postgresql.org/message-id/20220114234947.av4kkhuj7netsy5r%40alap3.anarazel.de




The buildfarm is moving in the opposite direction, to disaggregate
steps. There are several reasons for that, including that it makes for
less log output that you need to churn through o find out what's gone
wrong in a particular case, and that it makes disabling certain test
sets via the buildfarm client's `skip-steps' feature possible.


cheers


andrew

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




pgsql-hackers by date:

Previous
From: Zhihong Yu
Date:
Subject: Re: a misbehavior of partition row movement (?)
Next
From: Bharath Rupireddy
Date:
Subject: Re: Blank archive_command