Horton

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

Andrew Dunstan <andrew@dunslane.net>

View thread View on postgr.es
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-10-03T03:32:36Z
Lists: pgsql-hackers 
On 10/2/21 5:03 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> I haven't looked at the patch closely yet, but from a buildfarm POV I
>> think the only thing that needs to be done is to inhibit the buildfarm
>> client module if the TAP tests are present. The buildfarm code that runs
>> TAP tests should automatically detect and run the new test.
>> I've just counted and there are 116 animals reporting check-pg_upgrade,
>> so we'd better put that out pronto. It's a little early but I'll try to
>> push out a release containing code for it on Monday or Tuesday (it's a
>> one line addition).
> IIUC, the only problem for a non-updated animal would be that it'd
> run the test twice?  Or would it actually fail?  If the latter,
> we'd need to sit on the patch rather longer.
>
> 			


The patch removes test.sh, so yes it would break.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Commits

  1. Improve and fix some issues in the TAP tests of pg_upgrade

  2. Fix several issues with the TAP tests of pg_upgrade

  3. Make upgradecheck a no-op in MSVC's vcregress.pl

  4. Switch the regression tests of pg_upgrade to use TAP tests

  5. Fix check for PGHOST[ADDR] in pg_upgrade with Windows and temporary paths

  6. Remove REGRESS_OUTPUTDIR environment variable.

  7. Add PostgreSQL::Test::Cluster::config_data()