Re: JDBC specific Buildfarm member - Mailing list pgsql-jdbc

From Andrew Dunstan
Subject Re: JDBC specific Buildfarm member
Date
Msg-id 4DC1D088.3040005@dunslane.net
Whole thread Raw
Responses Re: JDBC specific Buildfarm member  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: JDBC specific Buildfarm member  (Mike Fowler <mike@mlfowler.com>)
List pgsql-jdbc

On 05/04/2011 05:17 PM, Mike Fowler wrote:
> Hi Andrew/Alvaro,
>
> I've just received the animal "piapiac" for my buildfarm which will
> run for 8.4, 9.0 and HEAD. I've created a JDBC module which is invoked
> during the locale testing once the database is running. It's activated
> by a new configuration parameter in build-farm.conf (set to undef in
> the attached patch). When invoked the module updates the JDBC source,
> builds and runs the tests for jdks 4, 5 and 6. In order to report the
> distinct JDBC failures I've added the following "stages" for the
> purposes of the send_result function:
>
> JDBC-CVS - SCM related problems, the JDBC code is in CVS
> JDBC-Clean - clearing out the previous build fails
> JDBC-JDK - the JDK's configuration is incorrect
> JDBC-Build - compiler failures
> JDBC-Create - creating the test user/database/lang failed
> JDBC-Test-Config - creating the overridden properties for the JUnit
> failed
> JDBC-Test - any JUnit failures/errors
> JDBC-Drop- dropping the test database/user failed
>
> Currently the module assumes that Apache ant is installed and the the
> JUnit jar file resides in the path - on Ubuntu it's simply "sudo
> apt-get install ant junit".
>
> The JDBC module isn't complete and could do with some more tweaks, but
> it is running and I've been able to test most of the failure
> conditions locally. Of course things might be different in the "wild".
> A couple of sore thumbs that stick out is that the JDBC specific
> configuration (e.g. the paths to the jdks) is baked in to the module
> and the JDBC suite is run for each locale which may be overkill. I'll
> continue to refine and provide you patches if you're interested in the
> code.
>
> As I'm running this one of the "free" Amazon EC2 micro instances I've
> got it configured to run one of the three development branches every 8
> hours (HEAD,REL9_0_STABLE,REL8_4_STABLE) with all three JDKs being
> tested with fresh code from the JDBC repo each time. Hopefully I'll
> remain within my free usage!
>
> If you're happy with this I will enable my buildfarm member.



This looks pretty good.

You should probably fill in $steps_completed. You'd need to change its
declaration so it was visible - change it so the declarations is :

    use vars qw($steps_completed);

As a matter of style, I stopped using globs for file handles long ago,
in favor of local variables. It would be best to keep to that style for
consistency (although you've done a pretty good job on that front, I
must say.)

Go ahead and enable it and let's see the results on the server.

Maybe I should factor out the core tests in a similar fashion.

Nice work.

cheers

andrew



pgsql-jdbc by date:

Previous
From: Craig Ringer
Date:
Subject: Re: PSQLException Can't infer the SQL type to use with Native Query call
Next
From: Alvaro Herrera
Date:
Subject: Re: JDBC specific Buildfarm member