Re: Extracting cross-version-upgrade knowledge from buildfarm client

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Extracting cross-version-upgrade knowledge from buildfarm client
Дата
Msg-id 3752447.1674070321@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Extracting cross-version-upgrade knowledge from buildfarm client  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Extracting cross-version-upgrade knowledge from buildfarm client  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
One more thing before we move on from this topic.  I'd been testing
modified versions of the AdjustUpgrade.pm logic by building from a
--from-source source tree, which seemed way easier than dealing
with a private git repo.  As it stands, TestUpgradeXversion.pm
refuses to run under $from_source, but I just diked that check out
and it seemed to work fine for my purposes.  Now, that's going to be
a regular need going forward, so I'd like to not need a hacked version
of the BF client code to do it.

Also, your committed version of TestUpgradeXversion.pm breaks that
use-case because you did

-   unshift(@INC, "$self->{pgsql}/src/test/perl");
+   unshift(@INC, "$self->{buildroot}/$this_branch/pgsql/src/test/perl");

which AFAICS is an empty directory in a $from_source run.

I suppose that the reason for not running under $from_source is to
avoid corrupting the saved installations with unofficial versions.
However, couldn't we skip the "save" step and still run the upgrade
tests against whatever we have saved?  (Maybe skip the same-version
test, as it's not quite reflecting any real case then.)

Here's a quick draft patch showing what I have in mind.  There may
well be a better way to deal with the wheres-the-source issue than
what is in hunk 2.  Also, I didn't reindent the unchanged code in
sub installcheck, and I didn't add anything about skipping
same-version tests.

            regards, tom lane

diff --git a/PGBuild/Modules/TestUpgradeXversion.pm b/PGBuild/Modules/TestUpgradeXversion.pm
index a784686..408432d 100644
--- a/PGBuild/Modules/TestUpgradeXversion.pm
+++ b/PGBuild/Modules/TestUpgradeXversion.pm
@@ -51,8 +51,6 @@ sub setup
     my $conf      = shift;    # ref to the whole config object
     my $pgsql     = shift;    # postgres build dir

-    return if $from_source;
-
     return if $branch !~ /^(?:HEAD|REL_?\d+(?:_\d+)?_STABLE)$/;

     my $animal = $conf->{animal};
@@ -351,7 +349,16 @@ sub test_upgrade    ## no critic (Subroutines::ProhibitManyArgs)
       if $verbose;

     # load helper module from source tree
-    unshift(@INC, "$self->{buildroot}/$this_branch/pgsql/src/test/perl");
+    my $source_tree;
+    if ($from_source)
+    {
+        $source_tree = $self->{pgsql};
+    }
+    else
+    {
+        $source_tree = "$self->{buildroot}/$this_branch/pgsql";
+    }
+    unshift(@INC, "$source_tree/src/test/perl");
     require PostgreSQL::Test::AdjustUpgrade;
     PostgreSQL::Test::AdjustUpgrade->import;
     shift(@INC);
@@ -694,6 +701,11 @@ sub installcheck
     my $upgrade_loc          = "$upgrade_install_root/$this_branch";
     my $installdir           = "$upgrade_loc/inst";

+    # Don't save in a $from_source build: we want the saved trees always
+    # to correspond to branch tips of the animal's standard repo.  We can
+    # perform upgrade tests against previously-saved trees, though.
+    if (!$from_source)
+    {
     # for saving we need an exclusive lock.
     get_lock($self, $this_branch, 1);

@@ -716,6 +728,7 @@ sub installcheck
       if ($verbose > 1);
     send_result('XversionUpgradeSave', $status, \@saveout) if $status;
     $steps_completed .= " XVersionUpgradeSave";
+    }

     # in saveonly mode our work is done
     return if $ENV{PG_UPGRADE_SAVE_ONLY};
@@ -744,7 +757,7 @@ sub installcheck
         # other branch from being removed or changed under us.
         get_lock($self, $oversion, 0);

-        $status =
+        my $status =
           test_upgrade($self, $save_env, $this_branch, $upgrade_install_root,
             $dport, $install_loc, $other_branch) ? 0 : 1;


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: document the need to analyze partitioned tables
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Non-superuser subscription owners