pgsql: pg_regress: Replace exit_nicely() with exit() plus atexit() hook

On 01/02/2012 03:12 PM, Peter Eisentraut wrote:

pg_regress: Replace exit_nicely() with exit() plus atexit() hook

This appears to have broken the buildfarm.

cheers

andrew

On mån, 2012-01-02 at 15:55 -0500, Andrew Dunstan wrote:

On 01/02/2012 03:12 PM, Peter Eisentraut wrote:

pg_regress: Replace exit_nicely() with exit() plus atexit() hook

This appears to have broken the buildfarm.

I think you mean it has caused the build to fail on some buildfarm
members. AFAICT, the buildfarm itself is still intact.

I think there is some room for improvement there:

- Why is the isolation test not part of check-world/installcheck-world?

- Why do the Windows buildfarm members report the failure in "make" and
the others in "isolationcheck"? Shouldn't those build systems behave
consistently?

- Could we get the buildfarm server to send out emails whenever a build
fails?

On 01/02/2012 04:37 PM, Peter Eisentraut wrote:

On mån, 2012-01-02 at 15:55 -0500, Andrew Dunstan wrote:

On 01/02/2012 03:12 PM, Peter Eisentraut wrote:

pg_regress: Replace exit_nicely() with exit() plus atexit() hook

This appears to have broken the buildfarm.

I think you mean it has caused the build to fail on some buildfarm
members. AFAICT, the buildfarm itself is still intact.

This is hardly the first use of this idiom.

I think there is some room for improvement there:

- Why is the isolation test not part of check-world/installcheck-world?

The buildfarm does not use the -world targets, for several reasons,
including:

* they don't exist in all branches
* they didn't exist when the script was written
* doing so would reduce the ability to tell the script to miss certain
steps on the command line
* not all members are set up to build the docs

I'm a fan of the -world targets (I created them, after all), but they
aren't always appropriate.

- Why do the Windows buildfarm members report the failure in "make" and
the others in "isolationcheck"? Shouldn't those build systems behave
consistently?

The MSVC build system has always been a bit different. It builds
everything that needs to be compiled in the make step. If you want to
rewrite it, feel free, but this seems a fairly minor difference.

- Could we get the buildfarm server to send out emails whenever a build
fails?

This facility has been there for years (almost from day one of the
buildfarm, the archives go back to June 2005), and have been previously
mentioned here. There are four status mailing lists you can subscribe to
at <http://pgfoundry.org/mail/?group_id=1000040&gt;. They can be got in
both individual and digest forms. They correspond to the following:

* all builds
* build that fail
* builds that have a different state from the last build
* builds that cause a state change to or from the OK ('green') state.

cheers

andrew

On mån, 2012-01-02 at 17:27 -0500, Andrew Dunstan wrote:

On 01/02/2012 04:37 PM, Peter Eisentraut wrote:

On mån, 2012-01-02 at 15:55 -0500, Andrew Dunstan wrote:

On 01/02/2012 03:12 PM, Peter Eisentraut wrote:

pg_regress: Replace exit_nicely() with exit() plus atexit() hook

This appears to have broken the buildfarm.

I think you mean it has caused the build to fail on some buildfarm
members. AFAICT, the buildfarm itself is still intact.

This is hardly the first use of this idiom.

But it's about as helpful as a bug report saying "help it's broken".

I think there is some room for improvement there:

- Why is the isolation test not part of check-world/installcheck-world?

The buildfarm does not use the -world targets, for several reasons,
including:

That was not my question. I run check-world/installcheck-world locally,
and if the isolation test had been part of this, this problem wouldn't
have happened.

- Could we get the buildfarm server to send out emails whenever a build
fails?

This facility has been there for years

Cool, maybe it could be advertised on buildfarm.postgresql.org. I
couldn't see any link leading from there to anywhere near the mailing
lists.

On 01/03/2012 06:29 PM, Peter Eisentraut wrote:

I think there is some room for improvement there:

- Why is the isolation test not part of check-world/installcheck-world?

The buildfarm does not use the -world targets, for several reasons,
including:

That was not my question. I run check-world/installcheck-world locally,
and if the isolation test had been part of this, this problem wouldn't
have happened.

I have no idea why. It was probably an oversight when the isolation
tests were added. I guess something like this would fix it?

    diff --git a/GNUmakefile.in b/GNUmakefile.in
    index 50fae41..5976832 100644
    --- a/GNUmakefile.in
    +++ b/GNUmakefile.in
    @@ -68,7 +68,7 @@ check installcheck installcheck-parallel:

$(call recurse,check-world,src/test src/pl src/interfaces/ecpg
contrib,check)

    -$(call recurse,installcheck-world,src/test src/pl
    src/interfaces/ecpg contrib,installcheck)
    +$(call recurse,installcheck-world,src/test src/test/isolation
    src/pl src/interfaces/ecpg contrib,installcheck)

$(call recurse,maintainer-check,doc src config contrib)

The isolation tests only run installcheck, not plain check. See the
archives for details of why.

- Could we get the buildfarm server to send out emails whenever a build
fails?

This facility has been there for years

Cool, maybe it could be advertised on buildfarm.postgresql.org. I
couldn't see any link leading from there to anywhere near the mailing
lists.

OK, I'll look at providing links from the web site to the lists.

cheers

andrew

On Tue, Jan 3, 2012 at 6:29 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

On mån, 2012-01-02 at 17:27 -0500, Andrew Dunstan wrote:

On 01/02/2012 04:37 PM, Peter Eisentraut wrote:

On mån, 2012-01-02 at 15:55 -0500, Andrew Dunstan wrote:

On 01/02/2012 03:12 PM, Peter Eisentraut wrote:

pg_regress: Replace exit_nicely() with exit() plus atexit() hook

This appears to have broken the buildfarm.

I think you mean it has caused the build to fail on some buildfarm
members.  AFAICT, the buildfarm itself is still intact.

This is hardly the first use of this idiom.

But it's about as helpful as a bug report saying "help it's broken".

I don't see why. Normally you can just go to buildfarm.postgresql.org
and see which machines are failing and at what stage, and the view the
stage logs to see the specific errors. It's not the best web
interface I've ever seen, but it's not *that* bad.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 01/03/2012 09:00 PM, Robert Haas wrote:

Normally you can just go to buildfarm.postgresql.org
and see which machines are failing and at what stage, and the view the
stage logs to see the specific errors. It's not the best web
interface I've ever seen, but it's not *that* bad.

And if someone wants to improve it they are welcome. The code is at
<https://github.com/PGBuildFarm/server-code&gt;. It helps if you know
Template Toolkit :-)

cheers

andrew