Thread: buildfarm improvements
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. cheers andrew
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