[TIP] Everybody wants a pony!

[Kumar McMillan]

On Tue, Mar 31, 2009 at 9:32 AM, C. Titus Brown <ctb at msu.edu> wrote:
> Hi all,
>
> one thing that became clear at PyCon this year is that everyone wants a
> pony.  Preferably a pink pony.
>
> (You had to be there.)
>
> Anyway, along the lines of a pony, I am proposing to build or extend a
> replacement for buildbot that will serve those of you who need a simpler
> and more easily-installable continuous interation framework.  I have a
> few basic ideas, but I'd love to hear what everyone else has to say.

I hate to be "that guy;" I love Python, really I do, but what I love
more is when a great open source tool with great documentation and a
community of maintainers solves a problem better than any other tool.
It makes the decision process easy.

It's called Hudson:
https://hudson.dev.java.net/

Yes, it is written in Java but Java is ubiquitous and Hudson is light
years beyond Buildbot.  Anyone (i.e. non-programmers) can configure
builds and workflows very easily.

If not obvious from the documentation, you can build and test
anything, it doesn't have to be Java.  At Leapfrog we have converted
all of our Python and Ruby buildbots to Hudson (oh did I say that out
loud?) and have never been happier or more efficient in how we do
continuous integration.  You don't need anything special in your tests
to use Hudson but you get some extra details (that buildbot never
provided) if you use xunit style test output.  There are several nose
plugins for this like Nosexunit -- the androgynous plugin.  Example:
nosetests --with-nosexunit

Titus, if you *must* spend your precious spare time (your hourly rate
is what now? priceless?) on this then at the very least make a Python
clone of Hudson :)  But seriously, give it a fair try and I think
you'll like it.

It has a plugin system too.  I assume one could write plugins using Jython even.


>
> Roughly speaking, I'd like to have pony-build do the following, relative
> to buildbot:
>
>  - "push" results from the client back to the server over an RPC
>   connection, rather than have the server control the client.
>   (That is, base it on a polling model rather than a remote control
>   model.)
>
>  - Be trivially installable on clients (a single "easy_install" that
>   works, even for Steve Holden).
>
>  - A separable and flexible reporting server to support RPC queries and
>   programmable workflows.
>
>  - A separable and flexible scheduling/config server to support build
>   requests and request builds on specific servers.
>
>  - "Anonymous" push of results, so that Joe Blow users can build,
>   compile, test, and send the results back to the server for your
>   examination, without breaking a sweat.
>
>  - Push of metadata to the reporting server for e.g. communication of
>   coverage data.
>
>  - distutils/setuptools and configure/make support.
>
> A lot of these ideas come from comparing DART with buildbot, and having
> good (and bad) experiences with both.
>
> We do have a prototype up and running and I'll try to get a screencast
> up within a week or two.
>
> Your thoughts welcome!
>
> cheers,
> --titus
> --
> C. Titus Brown, ctb at msu.edu
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>