Re: "make check" changes have caused buildfarm deterioration.
От | Michael Paquier |
---|---|
Тема | Re: "make check" changes have caused buildfarm deterioration. |
Дата | |
Msg-id | CAB7nPqTJoaosA1j37wVQUNwMOpgkZ9znzHYY7+xbT3=gDGY5EQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: "make check" changes have caused buildfarm deterioration. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "make check" changes have caused buildfarm deterioration.
Re: "make check" changes have caused buildfarm deterioration. Re: "make check" changes have caused buildfarm deterioration. |
Список | pgsql-hackers |
On Tue, Jul 21, 2015 at 6:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andrew Dunstan <andrew.dunstan@pgexperts.com> writes: >> Somewhere along the way some changes to the way we do "make check" have >> caused a significant deterioration in the buildfarm's logging. Compare >> these two from animal crake, which happens to be my test instance: >> <http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2015-07-20%2013%3A09%3A02&stg=check> >> and >> <http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2015-07-20%2017%3A23%3A08&stg=check> > > Yeah, I've been bitching about the poor logging for awhile, but I had > not realized that it's still working as-expected in the back branches. > > Comparing different branches, it looks like "somewhere along the way" > means "between 9.4 and 9.5". I suspect that commit dcae5faccab64776, or > perhaps the followon dbf2ec1a1c053379, is to blame. Regarding install.log, the use of stdout/stderr instead of a log file has been changed in dbf2ec1a after that: http://www.postgresql.org/message-id/553FE7FC.2040707@gmx.net Since 9.5 as the location of the temporary installation is global, we could basically revert some parts of dcae5fac if that helps so as install.log is saved in $ROOT/tmp_install/log/install.log... But I am not sure what we win with that, and the argument to remove install.log is that now the temporary installation is a make target. Both ways have advantages and disadvantages. Regarding initdb.log and postmaster.log, this is definitely a bug. Those have been moved by dcae5fa from log/ to tmp_check/log/, tmp_check/ getting removed at the end of pg_regress if there are no failures counted. Both files will be saved in log/ at the location pg_regress is called using outputdir whose default is ".". This way behavior is similar to ~9.4. Attached is a patch to fix this for 9.5 and master. Regards, -- Michael
Вложения
В списке pgsql-hackers по дате отправления: