Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add basic TAP test setup for pg_upgrade

  1. pgsql: Add basic TAP test setup for pg_upgrade

    Peter Eisentraut <peter_e@gmx.net> — 2017-09-19T22:56:14Z

    Add basic TAP test setup for pg_upgrade

The plan is to convert the current pg_upgrade test to the TAP
framework.  This commit just puts a basic TAP test in place so that we
can see how the build farm behaves, since the build farm client has some
special knowledge of the pg_upgrade tests.

Author: Michael Paquier <michael.paquier@gmail.com>

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/f41e56c76e39f02bef7ba002c9de03d62b76de4d

Modified Files
--------------
src/bin/pg_upgrade/Makefile       | 7 ++++---
src/bin/pg_upgrade/t/001_basic.pl | 9 +++++++++
2 files changed, 13 insertions(+), 3 deletions(-)

  2. Re: pgsql: Add basic TAP test setup for pg_upgrade

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-09-20T16:18:23Z

    Peter Eisentraut <peter_e@gmx.net> writes:
> Add basic TAP test setup for pg_upgrade
> The plan is to convert the current pg_upgrade test to the TAP
> framework.  This commit just puts a basic TAP test in place so that we
> can see how the build farm behaves, since the build farm client has some
> special knowledge of the pg_upgrade tests.

I hope you're not planning to leave it like this very long.  The
pg_upgrade test is already one of the longest steps in the buildfarm
runs, and now we're doing it twice.

			regards, tom lane

  3. Re: [COMMITTERS] pgsql: Add basic TAP test setup for pg_upgrade

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2017-09-20T22:48:48Z

    On 9/20/17 12:18, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> Add basic TAP test setup for pg_upgrade
>> The plan is to convert the current pg_upgrade test to the TAP
>> framework.  This commit just puts a basic TAP test in place so that we
>> can see how the build farm behaves, since the build farm client has some
>> special knowledge of the pg_upgrade tests.
> 
> I hope you're not planning to leave it like this very long.  The
> pg_upgrade test is already one of the longest steps in the buildfarm
> runs, and now we're doing it twice.

Oh I see what is happening now.  The buildfarm code looks for "t"
directories and runs tests there, and is at the same time hardcoded to
run check in the pg_upgrade directory.

So this will apparently require a buildfarm client code update after all.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services