Re: "make check" changes have caused buildfarm deterioration.

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(dot)dunstan(at)pgexperts(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "make check" changes have caused buildfarm deterioration.
Date: 2015-07-22 01:31:03
Message-ID: CAB7nPqT05Sz4ObnMXd=Hy_EAWWrABtmZi=thUtKBZ3Da2aBpjg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 22, 2015 at 10:04 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 7/21/15 10:00 AM, Tom Lane wrote:
>> I agree; this change may have seemed like a good idea at the time, but
>> it was not. Failures during "make check"'s install step are rare enough
>> that you don't really need all that output in your face to help with the
>> rare situation where it fails. And for the buildfarm's purposes, it is
>> surely desirable to segregate that output from the actual check step.
>
> It wasn't really an idea; it was just not necessary anymore. We can put
> it [directing the make install output into a file] back if that's what
> people prefer.

OK... Attached are two patches (please merge them into a single
commit, I am just separating them as they are separate issues):
- 0001 adds a missing entry in test_ddl_deparse's .gitignore. I
mentioned that upthread.
- 0002 redirects the installation logs into
abs_top_builddir/tmp_install/log/install.log. We could redirect it
only to abs_top_builddir/log/ but tmp_install is not removed after a
run of a regression make target.
--
Michael

Attachment Content-Type Size
0001-Add-missing-entry-log-in-.gitignore-for-test_ddl_dep.patch application/x-patch 630 bytes
0002-Redirect-installation-output-of-make-check-into-a-lo.patch application/x-patch 1.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-07-22 02:56:10 Re: ALTER TABLE .. ADD PRIMARY KEY .. USING INDEX has dump-restore hazard
Previous Message Peter Eisentraut 2015-07-22 01:15:32 Re: pg_basebackup and replication slots