Re: Create shorthand for including all extra tests

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Create shorthand for including all extra tests
Date: 2024-01-20 08:22:55
Message-ID: d3f6977b-a082-4cef-a38f-72d17a84c329@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 15.01.24 09:54, Nazir Bilal Yavuz wrote:
> Hi,
>
> On Wed, 10 Jan 2024 at 23:48, Peter Eisentraut <peter(at)eisentraut(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2024-01-20 08:32:25 Re: Make documentation builds reproducible
Previous Message Yongtao Huang 2024-01-20 07:46:33 Re: Optimize duplicate code and fix memory leak in function fetch_remote_table_info()