On Sat, Feb 10, 2018 at 04:44:38PM +1300, Thomas Munro wrote:
> On Sat, Feb 10, 2018 at 4:32 PM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> I agree that it would be nice if the build farm (and my unofficial
>> patch tester for that matter) could automatically test the LDAP stuff
>> when running on a suitable system, but I think it would need to be
>> based not just on ifeq ($(with_ldap),yes) as you showed. I think the
>> test would need a way to report that it can't find slapd so it can't
>> run, but not consider that to be a hard failure. Or something like
>> that...
>
> Hmm. I guess I just changed the subject a bit there to running those
> tests from check-world, if possible, by default. But as
> src/test/Makefile says, those test suites "are not secure to run on a
> multi-user system".
Yeah, I am not advocating that. Note that the SSL tests could become
part of the default if we have one day a way do so SSL with a Unix
domain socket. There were some discussions a couple of years back but,
if I recall correctly, the arguing has stuck about the way to shape the
HBA entries for the configuration. There are also few use cases so the
enthusiasm has not lasted long.
> You're talking about making the tests not fail if
> you tried to run them directly (not from check-world, but by direct
> invocation) when you didn't build with the right options. I take back
> what I said: it's probably better if you run those tests explicitly
> when you know you have the prerequisites installed and you're OK with
> the security implications (for example I should probably just do that
> on those Travis CI patch tester builds). Sorry for the noise.
Yes, you need to go into the test's paths to run them as well. The
problem is also that the information provided by the TAP tests exploding
because the build does not support those is pretty useless. It is true
that you could filter things by using TestLib::check_pg_config, but do
we really want to spend cycles for that when a Makefile check can do the
job better and in a cheaper way?
--
Michael