On Sun, Mar 4, 2018 at 12:42 AM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 1/26/18 03:00, Michael Paquier wrote: >> As promised on a recent thread, here is a second tentative to switch >> pg_upgrade's test.sh into a TAP infrastructure. > > AFAICT, this still has the same problem as the previous take, namely > that adding a TAP test suite to the pg_upgrade subdirectory will end up > with the build farm client running the pg_upgrade tests twice. What we > likely need here is an update to the build farm client in conjunction > with this. > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
Something like this should do the trick. diff --git a/PGBuild/Modules/TestUpgrade.pm b/PGBuild/Modules/TestUpgrade.pm index 8406d27..05859f9 100644 --- a/PGBuild/Modules/TestUpgrade.pm +++ b/PGBuild/Modules/TestUpgrade.pm @@ -50,6 +50,11 @@ sub setup "overly long build root $buildroot will cause upgrade problems - try something shorter than 46 chars" if (length($buildroot) > 46); + # don't run module if builtin test is enabled. + my $using_tap_tests = $conf->using_msvc ? $conf->{config}->{tap_tests} : + grep {$_ eq '--enable-tap-tests'} @{$conf->{config}} ; + return if $using_tap_tests && -d "$buildroot/$branch/pgsql/src/bin/pg_upgrade/t"; + # could even set up several of these (e.g. for different branches) my $self = { buildroot => $buildroot, cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services