Re: Fwd: Re: [HACKERS] Running make check-world in buildfarm (was Re: [COMMITTERS] pgsql: Use SASLprep to normalize passwords for SCRAM authentication.)
От | Tom Lane |
---|---|
Тема | Re: Fwd: Re: [HACKERS] Running make check-world in buildfarm (was Re: [COMMITTERS] pgsql: Use SASLprep to normalize passwords for SCRAM authentication.) |
Дата | |
Msg-id | 10838.1491667860@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Fwd: Re: [HACKERS] Running make check-world in buildfarm (was Re:[COMMITTERS] pgsql: Use SASLprep to normalize passwords for SCRAMauthentication.) (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
Ответы |
Re: Fwd: Re: [HACKERS] Running make check-world in buildfarm (was Re:[COMMITTERS] pgsql: Use SASLprep to normalize passwords for SCRAMauthentication.)
|
Список | pgsql-hackers |
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? regards, tom lane
В списке pgsql-hackers по дате отправления: