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 по дате отправления: