attempting to enable buildbot

Hi all,

I am attempting to get a collective.buildbot service working on the
Matplotlib trunk (branches could be enabled in the future) and James
Evans' test suite. Right there are errors that prevent the test suite
from even being run. I'll attempt to work through these, and you can
check progress on the nascent buildbot display here:

http://mpl-buildbot.code.astraw.com

(If the DNS update hasn't propagated to your DNS server yet, you can go
directly to http://code.astraw.com:8092/ )

In the meantime, please forgive a couple extra files I committed
(bootstrap.py and buildout.cfg) that are designed to get matplotlib to
adhere to buildout package standards.

Assuming I can get this working, I'll attempt to recruit further
buildslaves. In the interest of piquing your interest in running a
buildslave on your favorite platform(s), here is the contents of my
buildout.cfg file containing all of the configuration necessary. It's
pretty simple:

[buildout]
parts = ubuntu-hardy-amd64

[ubuntu-hardy-amd64]
recipe = collective.buildbot:slave
host = mpl-buildbot.code.astraw.com
port = 8090
password = <secret>

Andrew Straw wrote:

Hi all,

I am attempting to get a collective.buildbot service working on the
Matplotlib trunk (branches could be enabled in the future) and James
Evans' test suite. Right there are errors that prevent the test suite
from even being run. I'll attempt to work through these, and you can
check progress on the nascent buildbot display here:

http://mpl-buildbot.code.astraw.com

OK, the tests are now actually running, although most of the tests are
failing, which is worse than when I run the tests manually. :frowning:

If anyone wants to attempt to get the tests passing, the buildmaster
should be configured to trigger a build on an svn commit (it is supposed
to poll the svn server every 10 minutes). You can also trigger a build
attempt by clicking the "Force Build" button after following the builder
link in the Web GUI (I may have to disable this if the load gets too high.)

Let's see if we can get all the tests passing and if this buildbot
approach looks sustainable -- if so, I'd like to get some more build
slaves into the mix and make MPL a good continuous integration citizen.
I don't think the buildbot master will take many resources on my server,
so I'm happy to host it there. I could put it under a different domain
name, too -- that may be desirable for marketing reasons.

-Andrew

Let's see if we can get all the tests passing and if this buildbot
approach looks sustainable -- if so, I'd like to get some more build
slaves into the mix and make MPL a good continuous integration citizen.
I don't think the buildbot master will take many resources on my server,

The sage project has given us access to a network accessible
persistent OSX box, so I will try and get that setup with the buildbot
infrastructure. I'm not yet familiar with the buildbot project or
approach, so I have some learning to do, so if you have a cheatsheet
or docs thaty you think are particularly handy, send them along
(otherwise I'll just make my way through the site docs)

so I'm happy to host it there. I could put it under a different domain
name, too -- that may be desirable for marketing reasons.

we can worry about marketing it once we have it doing something useful
:slight_smile: Thanks for pushing ahead on this.

JDH

···

On Wed, May 20, 2009 at 3:48 AM, Andrew Straw <strawman@...36...> wrote:

I’ll see if I can get the buildbot running on my gentoo AMD64 box.

Ryan

···

On Wed, May 20, 2009 at 3:48 AM, Andrew Straw <strawman@…36…> wrote:

Andrew Straw wrote:

Hi all,

I am attempting to get a collective.buildbot service working on the

Matplotlib trunk (branches could be enabled in the future) and James

Evans’ test suite. Right there are errors that prevent the test suite

from even being run. I’ll attempt to work through these, and you can

check progress on the nascent buildbot display here:

http://mpl-buildbot.code.astraw.com

OK, the tests are now actually running, although most of the tests are

failing, which is worse than when I run the tests manually. :frowning:

If anyone wants to attempt to get the tests passing, the buildmaster

should be configured to trigger a build on an svn commit (it is supposed

to poll the svn server every 10 minutes). You can also trigger a build

attempt by clicking the “Force Build” button after following the builder

link in the Web GUI (I may have to disable this if the load gets too high.)

Let’s see if we can get all the tests passing and if this buildbot

approach looks sustainable – if so, I’d like to get some more build

slaves into the mix and make MPL a good continuous integration citizen.

I don’t think the buildbot master will take many resources on my server,

so I’m happy to host it there. I could put it under a different domain

name, too – that may be desirable for marketing reasons.


Ryan May
Graduate Research Assistant

School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

Andrew Straw wrote:

I am attempting to get a collective.buildbot service working on the
Matplotlib trunk (branches could be enabled in the future) and James
Evans' test suite. Right there are errors that prevent the test suite
from even being run.

I believe I have enabled the unit test to properly run on the buildbot,
but it requires a patch to the buildout recipe (pbp.recipe.noserunner)
that runs the tests. I sent the patch to the author of
pbp.recipe.noserunner, so hopefully a new release will appear shortly
and I can take Ryan on John up on their offers of buildslaves, which
I'll coordinate off-list when the time is right.

In the meantime, the essential part of the pbp.recipe.noserunner patch is:

diff -r 8e8141beee8d
packages/pbp.recipe.noserunner/pbp/recipe/noserunner/__init__.py
--- a/packages/pbp.recipe.noserunner/pbp/recipe/noserunner/__init__.py
Wed May 13 12:03:55 2009 +0200
+++ b/packages/pbp.recipe.noserunner/pbp/recipe/noserunner/__init__.py
Wed May 20 15:08:27 2009 -0700
@@ -61,6 +61,13 @@
         if initialization_section:
             initialization += initialization_section

+ plugins = options.get('plugins', '')
+ plugins = [plugin.strip() for plugin in plugins.split('\n') if
plugin.strip() != '']

···

+
+ if len(plugins):
+ plugin_str = ','.join( plugins )
+ defaults += ", plugins=[%s]"%plugin_str
+
         dest.extend(zc.buildout.easy_install.scripts(
             [(options['script'], 'nose', 'main')],
             ws, options['executable'],

If you've applied that, you'll have to add to the "develop" section of
the buildout file the line "/path/to/pbp.recipe.noserunner" (in addition
to the "."). From there, it's standard zc.buildout recipes in the MPL dir:

python bootstrap.py # create bin/buildout
bin/buildout # build MPL and create bin/test
bin/test # run the unit tests

Since these are the steps that the buildbot follows, this should also
work on the build slaves once we no longer need the custom
pbp.recipe.noserunner. If it looks like it'll be a while before a new
pbp.recipe.noserunner is released, I think we could temporarily host a
patched version and direct buildout to it with the find-links option.

-Andrew

The tests now seem to be running OK. There are some failures due to
image comparison mismatch, but I think we should attempt to track these
down as a team -- hopefully running on more computers than just mine and
with James' input. To see the latest test results, click on the "stdio"
link for each run of the "test" box in the waterfall display
http://mpl-buildbot.code.astraw.com/waterfall .

It would be nice if the buildbot web GUI would easily let us see, for
failed image-based tests, the baseline, output, and difference image,
but that's not implemented (as far as I know). It would probably be
possible to add something like this to the MplNosePlugin to do this with
relatively little pain, although the display would be easiest via a
pastebin or something rather than hooking back into a patched buildbot
framework that supported test images.

John Hunter wrote:

Let's see if we can get all the tests passing and if this buildbot
approach looks sustainable -- if so, I'd like to get some more build
slaves into the mix and make MPL a good continuous integration citizen.
I don't think the buildbot master will take many resources on my server,

The sage project has given us access to a network accessible
persistent OSX box, so I will try and get that setup with the buildbot
infrastructure. I'm not yet familiar with the buildbot project or
approach, so I have some learning to do, so if you have a cheatsheet
or docs thaty you think are particularly handy, send them along
(otherwise I'll just make my way through the site docs)

OK, here's what you do::

  # (Make a username you want to run this buildslave as.
  # Become that user. Change into a new directory e.g. $HOME/builbot)

  curl http://astraw.com/mpl/bootstrap-py.txt > bootstrap.py
  curl http://astraw.com/mpl/buildout-example.cfg > buildout.cfg

  # Edit buildout.cfg according the instructions in the file. Send me
  # the values you added.

  # python bootstrap.py
  # bin/buildout

Once you've been added to the build master:

  # bin/<slave-identifier-string> start

And that should be it.

For now we can start/stop builds by clicking the "force build" button in
the buildmaster web GUI. SVN polling doesn't seem to be working yet...
I'll look into that when I have time. Ditto for building binaries and
uploading them somewhere.

-Andrew

···

On Wed, May 20, 2009 at 3:48 AM, Andrew Straw <strawman@...36...> wrote: