I've been giving some thought to $subject. The initial impetus is the
promise I made to assist with testing of clients built with NSS against
servers built with openssl, and vice versa.
I've already generalized the process of saving binaries by the buildfarm
client. And we could proceed with a purely bespoke module for testing
the SSL components, as we already do for testing cross-version
pg_upgrade. But it struck me that it might be better to leverage our
existing investment in TAP tests. So I came up with the idea of creating
a child module of PostgresNode.pm, which would set the PATH and other
variables appropriately at the start of each method and restore them on
method exit. So then we could have things like:
$openssl_node->start;
my $connstr = $openssl_node->connstr;
$nss_node->psql($connstr, ...);
To use this a TAP test would need to know two (or more) install paths
for the various nodes, presumably set in environment variables much as
we do now for things like TESTDIR. So for the above example, the TAP
test could set things up with:
my
$openssl_node=PostgresNodePath::get_new_node($ENV{OPENSSL_POSTGRES_INSTALL_PATH},'openssl');
my
$nss_node=PostgresNodePath::get_new_node($ENV{NSS_POSTGRES_INSTALL_PATH},'nss');
Other possible uses would be things like cross-version testing of
pg_dump (How do we know we haven't broken anything in dumping very old
versions?).
The proposed module would look something like this:
package PostgresNodePath;
use strict;
use warnings;
use parent PostgresNode;
use Exporter qw(import);
our @EXPORT = qw(get_new_node);
sub get_new_node
{
my $installpath= shift;
my $node = PostgresNode::get_new_node(@_);
bless $node; # re-bless into current class
$node->{_installpath} = $installpath;
return $node;
}
and then for each class method in PostgresNode.pm we'd have an override
something like:
sub foo
{
my $node=shift;
my $inst = $node->{_installpath};
local %ENV = %ENV;
$ENV{PATH} = "$inst/bin:$ENV{PATH}";
$ENV{LD_LIBRARY_PATH} = "$inst/lib:$ENV{LD_LIBRARY_PATH}";
$node->SUPER::foo(@_);
}
There might be more elegant ways of doing this, but that's what I came
up with.
My main question is: do we want something like this in the core code
(presumably in src/test/perl), or is it not of sufficiently general
interest? If it's wanted I'll submit a patch, probably for the March CF,
but January if I manage to get my running shoes on. If not, I'll put it
in the buildfarm code, but then any TAP tests that want it will likewise
need to live there.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
