vcregress support for single TAP tests
Here's a patch that will allow calling vcregress.pl to run a single TAP
test set. It would work like this:
vcregress.pl src/test/recover true
The second argument if true (in the perl sense, of course) would trigger
a temp install before running the tests. It defaults to off, in an
attempt to minimize the unnecessary running of installs.
Once we have this I will switch the buildfarm client to use it. The
previous bincheck procedure is kept to avoid breakage of scripts,
buildfarm clients etc.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
vcregress-tap.patchtext/x-diff; name=vcregress-tap.patchDownload+25-15
On 4/23/17 17:09, Andrew Dunstan wrote:
Here's a patch that will allow calling vcregress.pl to run a single TAP
test set. It would work like this:vcregress.pl src/test/recover true
The second argument if true (in the perl sense, of course) would trigger
a temp install before running the tests. It defaults to off, in an
attempt to minimize the unnecessary running of installs.
Seems kind of weird to have that functionality only for the tap tests,
though.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 04/26/2017 10:32 PM, Peter Eisentraut wrote:
On 4/23/17 17:09, Andrew Dunstan wrote:
Here's a patch that will allow calling vcregress.pl to run a single TAP
test set. It would work like this:vcregress.pl src/test/recover true
The second argument if true (in the perl sense, of course) would trigger
a temp install before running the tests. It defaults to off, in an
attempt to minimize the unnecessary running of installs.Seems kind of weird to have that functionality only for the tap tests,
though.
Yeah, you're right, I think we'd be much better mimicking what the
makefiles do and honouring the NO_TEMP_INSTALL environment variable.
Revised patch that works that way attached.
So to run an arbitrary TAP test set, you would do (for example)
vcregress.pl taptest src/test/recover
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
vcregress-tap2.patchtext/x-diff; name=vcregress-tap2.patchDownload+29-17
On 04/28/2017 08:54 AM, Andrew Dunstan wrote:
On 04/26/2017 10:32 PM, Peter Eisentraut wrote:
On 4/23/17 17:09, Andrew Dunstan wrote:
Here's a patch that will allow calling vcregress.pl to run a single TAP
test set. It would work like this:vcregress.pl src/test/recover true
The second argument if true (in the perl sense, of course) would trigger
a temp install before running the tests. It defaults to off, in an
attempt to minimize the unnecessary running of installs.Seems kind of weird to have that functionality only for the tap tests,
though.Yeah, you're right, I think we'd be much better mimicking what the
makefiles do and honouring the NO_TEMP_INSTALL environment variable.
Revised patch that works that way attached.So to run an arbitrary TAP test set, you would do (for example)
vcregress.pl taptest src/test/recover
In the absence of further comments I'm going to apply this and
back-patch it so we can get a significant improvement in how the
buildfarm reports results from TAP tests, as well as increased coverage,
on Windows/MSVC machines.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 1, 2017 at 11:01 PM, Andrew Dunstan <
andrew.dunstan@2ndquadrant.com> wrote:
In the absence of further comments I'm going to apply this and
back-patch it so we can get a significant improvement in how the
buildfarm reports results from TAP tests, as well as increased coverage,
on Windows/MSVC machines.
I see vcregress is not processing the second argument passed to it. For
example, "vcregress.bat check serial" runs the regress test in parallel
mode.
Though this issue is present even before this patch is applied, am writing
here because this patch touches the argument passing to sub-routine logic.
Attached is the one fix I find it working for me.
Thanks & Regards,
Vaishnavi,
Fujitsu Australia.
Attachments:
0001-Argument-passing-to-sub-routine-corrected-in-vcregre.patchapplication/octet-stream; name=0001-Argument-passing-to-sub-routine-corrected-in-vcregre.patchDownload+1-2
On 05/02/2017 12:19 AM, Vaishnavi Prabakaran wrote:
On Mon, May 1, 2017 at 11:01 PM, Andrew Dunstan
<andrew.dunstan@2ndquadrant.com
<mailto:andrew.dunstan@2ndquadrant.com>> wrote:In the absence of further comments I'm going to apply this and
back-patch it so we can get a significant improvement in how the
buildfarm reports results from TAP tests, as well as increased
coverage,
on Windows/MSVC machines.I see vcregress is not processing the second argument passed to it.
For example, "vcregress.bat check serial" runs the regress test in
parallel mode.
Though this issue is present even before this patch is applied, am
writing here because this patch touches the argument passing to
sub-routine logic.
Attached is the one fix I find it working for me.
Oh, you're right, my bad. Thanks. Will apply.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers