Re: Adding CI to our tree

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Adding CI to our tree
Дата
Msg-id 87a81b91-87bf-c0bc-7e4f-06dffadcf737@dunslane.net
обсуждение исходный текст
Ответ на Re: Adding CI to our tree  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Adding CI to our tree  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Zhihong Yu
Дата:
Сообщение: Re: a misbehavior of partition row movement (?)
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Blank archive_command