On 27 Jun 2009, at 03:30, Mark Karpeles wrote:
Hi,
Le samedi 27 juin 2009 à 02:24 +0100, Scott MacVicar a écrit :
I think we should look at getting buildbot setup and deployed to as
many machines as humanly possible. It would at least give us a heads
up when we've written something that doesn't work.
You can see the ones for Google Chromium at
http://build.chromium.org/buildbot/waterfall/waterfall
It just needs someone to spend the time writing the initial slave
deployment script, any volunteers? :)
This looks like something that matches my subset of things I can do.
I already had some ideas about this, and already done an interface
that
can display various test information on a same page.
http://php.magicaltux.net/browse/ (lots of memleaks reported on 5.3 &
HEAD, seems to be glibc-related and not real memleaks, and this is not
up-to-date as I didn't run the tests for a while and didn't automate
it
because it takes a lot of cpu)
Of course we can also make something that looks like Google's
waterfall,
but I don't find it to be really easy to read.
The good thing with the interface I made is the fact you can see the
status for all modules directly, eg:
http://php.magicaltux.net/browse/ext/
I could, instead of providing branch columns provide instead arch
columns, and let the user select what he want to see before accessing
the interface (ie. compare all arch on branch PHP_5_3).
Anyway that is just an idea, the good part is that most of the code
has
been written, missing parts would be ability to remotely provide
compile
results (ie. run tests from a different arch) and make code looks
better
(I wrote this under influence of beer, the code is missing comments).
Would also need a deployment script as suggested by Scott that will
initialize a slave directly, saving the time required to install
this on
xxxxxxx comptuers.
I don't think I explained Buildbot properly, its more than just a test
runner, its kind of glue to join together an applications various
building and testing results and capture it all and report back to the
build master.
We'd just need to write a few dozen lines of configuration script that
tells the slaves what to do.
They aren't that hard, it just requires someone to sit and write the
first version.
You write a bootstrapping master.cfg in python and it can then spawn
whatever other language it wants, in our case probably the freshly
built PHP ;-)
From there it can run tests and do whatever we wish with the results,
like grab all test failures and upload it to your test result viewer.
If a build fails we can have it use twitter / irc to inform people
that a slave failed to build PHP for whatever reason.
It's also got various scheduling parts built in, so we can do
continuous regular builds to make sure its still compiling and daily
memory builds to check for new memory leaks.
Other cool features are notifying people when it broke via IRC,
twitter or mailing list. And optionally packaging the freshly built
tests and uploading them. We could hypothetically get our snapshots
built this way so we never release a broken snapshot?
The project URL is http://buildbot.net/trac and the vast documentation
is at http://djmitche.github.com/buildbot/docs/0.7.10/
I might be able to sit down and give this a go on the plane next week.
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
