On 04/08/2017 02:49 PM, Andrew Dunstan wrote:
>
> On 04/08/2017 12:11 PM, Tom Lane wrote:
>> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>>>> I think it's partially knowing which target failed, and which
>>>> regression.diffs to display. If we were able to revamp check-world so
>>>> it outputs a list of targets the regression machinery were able to run
>>>> individually, it'd probably help?
>>> Yes, I don't want just to run check-world.
>> Yup. The situation with the TAP tests (bin-check step) is already a
>> usability fail: when there's a failure, your first problem is to root
>> through megabytes of poorly-differentiated logs just to figure out
>> what actually failed. Treating all of check-world as a single buildfarm
>> step would be a disaster.
>>
>>> Instead of just adding targets to check-world, perhaps we need to look
>>> at what we can do so that the buildfarm client can discover what checks
>>> it might run and run them, just as we specify test schedules for pg_regress.
>> +1. In the meantime, is there any chance of breaking down bin-check into
>> a separate step per src/bin/ subdirectory?
>>
>>
> Possibly. I will look when I go to do the missing checks, later today or
> tomorrow.
>
OK, crake is running this code now. See
<https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2017-04-09%2001%3A58%3A15?
I've left off the SSL tests for now. We should look into how we can do
that more safely. Meanwhile Heikki is running the tests.
Note that some of these tests are quite expensive in terms of time,
particularly recover, subscription and pg_rewind.
This who want to play along can get the bleeding edge code from git,
either by cloning or grabbing a zip of the latest code. I have one or
two things I want to do before wrapping up another client release.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services