Re: Rewriting the test of pg_upgrade as a TAP test - take two - Mailing list pgsql-hackers

On Sun, Mar 4, 2018 at 12:42 AM, Peter Eisentraut
<peter.eisentraut@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