Re: Create shorthand for including all extra tests

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Create shorthand for including all extra tests
Дата
Msg-id d3f6977b-a082-4cef-a38f-72d17a84c329@eisentraut.org
обсуждение исходный текст
Ответ на Re: Create shorthand for including all extra tests  (Nazir Bilal Yavuz <byavuz81@gmail.com>)
Список pgsql-hackers
On 15.01.24 09:54, Nazir Bilal Yavuz wrote:
> Hi,
> 
> On Wed, 10 Jan 2024 at 23:48, Peter Eisentraut <peter@eisentraut.org> wrote:
>>
>> On 05.09.23 19:26, Nazir Bilal Yavuz wrote:
>>> Thanks for the feedback! I updated the patch, 'needs-private-lo'
>>> option enables kerberos, ldap, load_balance and ssl extra tests now.
>>
>> As was discussed, I don't think "needs private lo" is the only condition
>> for these tests.  At least kerberos and ldap also need extra software
>> installed, and load_balance might need editing the system's hosts file.
>> So someone would still need to familiarize themselves with these tests
>> individually before setting a global option like this.
>>
>> Also, if we were to create test groupings like this, I think the
>> implementation should be different.  The way you have it, there is a
>> sort of central registry of all affected tests in
>> src/test/perl/PostgreSQL/Test/Utils.pm and a mapping of groups to tests.
>>    I would prefer a more decentralized approach where each test decides
>> on its own whether to run, with pseudo-code conditionals like
>>
>> if (!(PG_TEST_EXTRA contains "ldap" or PG_TEST_EXTRA contains
>> "needs-private-lo"))
>>     skip_all
>>
>> Anyway, at the moment, I don't see a sensible way to group these things
>> beyond what we have now (effectively, "ldap" is already a group, because
>> it affects more than one test suite).  Right now, we have six possible
>> values, which is probably just about doable to keep track of manually.
>> If we get a lot more, then we need to look into this again, but maybe
>> then we'll also have more patterns to group things around.
> 
> I see your point. It looks like the best option is to reevaluate this
> if there are more PG_TEST_EXTRA options.

Ok, I'm closing this commitfest entry.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Yongtao Huang
Дата:
Сообщение: Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Make documentation builds reproducible