buildfarm improvements

Andrew Dunstan schrieb:

I have implemented several requested improvements, which I hope will
prove useful. Since this whole piece of work exists for the benefit of
the pg developers, I'm posting some info here.

The latest version includes these features:

. the log page shows the system type near the top
"OS/Compiler/Architecture"
. the log page shows the script configuration data (other than the
password) and including the script version number
. the changed files list(s) on the log page include CVS revision numbers.

An example showing all these can be seen at
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dog&dt=2004-12-17%2021:06:01

Constructive comments welcome as always.

Good.

What I also miss is the successful output of the make test step.

Something like the Log in "Details", just behind an additional request.
"Config" =>
Log
Link to "Details"

Without those details one doesn't trust the presented result.
He might think that only the build was successful, and not the make test
step also.
People I redirect to this page from other projects, not reading the
status pages everyday.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Reini Urban wrote:

What I also miss is the successful output of the make test step.

Something like the Log in "Details", just behind an additional request.
"Config" =>
Log
Link to "Details"

Without those details one doesn't trust the presented result.
He might think that only the build was successful, and not the make
test step also.
People I redirect to this page from other projects, not reading the
status pages everyday.

That would actually be a substantial change in the way it works.
Basically, it sends the log of the step that failed. That preserves
bandwidth and doesn't clog the database with success cases. These logs
are not inconsiderable - I just checked on the canonical system and for
the last successful run they were 640Kb. I was originally given this
(virtual) server on the basis of my assurance that the bandwidth and
database requirements would be very modest, so I'm inclined to keep to that.

Regarding your last sentence - the intended prime users are the
postgresql hackers. If it had a vastly more general audience I would
have produced something a good less spartan in style. I'm not quite sure
why you're redirecting people to the status pages from other projects.
This is not the official list of supported platforms, and is not
intended as a substitute for it.

Perhaps we could put a statement at the top of the details page saying
what steps have succeeded (which we could infer from the result). Of
course, if people don't want to believe it then they won't - having logs
should not make believing it any easier - faking the logs would be quite
trivial.

FYI here's what happens during a run - a status of OK means that *all*
of this has run successfully:

[andrew@aloysius buildfarm]$ ./run_build.pl --verbose
checking out source ...
checking if build run needed ...
copying source to pgsql.3034 ...
running configure ...
running make ...
running make check ...
running make contrib ...
running make install ...
setting up db cluster ...
starting db ...
running make installcheck ...
restarting db ...
running make contrib install ...
running make contrib installcheck ...
stopping db ...
OK

All the buildfarm members are known, by the way, and every status report
is signed with a SHA1 signature. We don't just accept anonymous reports.
In many cases I know these people from previous electronic interaction,
via email and/or IRC. That, more than the presence of success logs,
should give you some confidence in the results, I hope.

cheers

andrew

Andrew Dunstan schrieb:

Reini Urban wrote:

What I also miss is the successful output of the make test step.

Something like the Log in "Details", just behind an additional request.
"Config" =>
Log
Link to "Details"

Without those details one doesn't trust the presented result.
He might think that only the build was successful, and not the make
test step also.
People I redirect to this page from other projects, not reading the
status pages everyday.

That would actually be a substantial change in the way it works.
Basically, it sends the log of the step that failed. That preserves
bandwidth and doesn't clog the database with success cases. These logs
are not inconsiderable - I just checked on the canonical system and for
the last successful run they were 640Kb. I was originally given this
(virtual) server on the basis of my assurance that the bandwidth and
database requirements would be very modest, so I'm inclined to keep to
that.

Sure. Convinced.

Regarding your last sentence - the intended prime users are the
postgresql hackers. If it had a vastly more general audience I would
have produced something a good less spartan in style. I'm not quite sure
why you're redirecting people to the status pages from other projects.
This is not the official list of supported platforms, and is not
intended as a substitute for it.

Perhaps we could put a statement at the top of the details page saying
what steps have succeeded (which we could infer from the result). Of
course, if people don't want to believe it then they won't - having logs
should not make believing it any easier - faking the logs would be quite
trivial.

FYI here's what happens during a run - a status of OK means that *all*
of this has run successfully:

[andrew@aloysius buildfarm]$ ./run_build.pl --verbose
checking out source ...
checking if build run needed ...
copying source to pgsql.3034 ...
running configure ...
running make ...
running make check ...
running make contrib ...
running make install ...
setting up db cluster ...
starting db ...
running make installcheck ...
restarting db ...
running make contrib install ...
running make contrib installcheck ...
stopping db ...
OK

Printing this output would be enough for me, and other manager types.

All the buildfarm members are known, by the way, and every status report
is signed with a SHA1 signature. We don't just accept anonymous reports.
In many cases I know these people from previous electronic interaction,
via email and/or IRC. That, more than the presence of success logs,
should give you some confidence in the results, I hope.

--
Reini Urban