[OPEN-ILS-DEV] Continuous integration (was: Planning for Evergreen development, post 2.0)

[Dan Scott]

On Tue, Jan 25, 2011 at 11:20:48PM -0700, Brian Feifarek wrote:
> 
> dbs++
> 
> I think this would a great contribution to make development easier
> 
> > Date: Wed, 26 Jan 2011 00:22:23 -0500
> > From: dan at coffeecode.net
> > To: open-ils-dev at list.georgialibraries.org
> > Subject: Re: [OPEN-ILS-DEV] Planning for Evergreen development, post 2.0
> > 
> > On Fri, Jan 07, 2011 at 01:01:50PM -0500, Dan Scott wrote:
> > Something closer to reality than I would have expected a few days ago is
> > the possible return of continuous integration to Evergreen. I spent a
> > chunk of today putting together a CI server on a Debian Squeeze VM using
> > the buildbot project code from http://buildbot.net and have a master
> > definition for OpenSRF that the build slave uses to follow commits and
> > automatically configure, compile, run unit tests, and run checks (like
> > pylint) against the updated source.

An update:

Thanks to Equinox for providing me with the credentials to access their
testing server; as of today we have a continuous integration server at
http://testing.evergreen-ils.org/buildbot that currently is tracking
OpenSRF trunk and running configure / compile / available unit tests /
pylint for every commit. It will attempt to send email to the
open-ils-dev mailing list if a failure occurs (I've told it to ignore
failures reported by pylint).

To-do: Lots! Some ideas: 

  * My highest priority: we need to start tracking Evergreen trunk and
    various branches; for that purpose, I hope we can secure
    one or more servers on which we can install OpenSRF and
    configure/compile/test Evergreen branches. Why a separate server
    for Evergreen, you ask? We need to have at least one "clean" server
    to build, compile, and test OpenSRF on without any files lingering
    from prevous OpenSRF installs (I discovered a lingering file was
    masking at least one unit test failure).

  * Add more build slaves to provide distribution coverage (for example,
    Debian Lenny vs. Debian Squeeze vs. RHEL 6 vs. Ubuntu Lucid). Build
    slaves don't require much horsepower, as (at least for the build
    target I currently have defined) they don't need to run OpenSRF or
    Evergreen. They just need to have the OpenSRF (and for Evergreen
    testing, Evergreen) prereqs installed so that we can configure,
    compile, and run tests. Well, and the buildbot-slave Python package
    needs to be installed so that they can talk to the build master.

  * Add more tests! Now that we're actually running tests regularly and
    reporting on failures, they have real value.

  * Add more build steps, such as creating release tarballs. That should
    be relatively straightforward for OpenSRF but there's a lot more
    required for Evergreen. Ideally most of the logic will be built into
    the Makefile where everyone can benefit instead of getting tucked
    into custom buildbot steps.

  * Customize the HTML templates for buildbot so that it integrates into
    the Evergreen project rather than being a completely separate beast.
    (A low priority IMHO compared to the others).

I have to say that working with buildbot has been close to painless.  I
wouldn't have anticipated being able to go from nothing to a working CI
server in a day and a half, but the documentation is thorough, the
source is easy to dive into when necessary, and the configuration file
is written in Python itself (ah Python!) - see
http://svn.open-ils.org/trac/OpenSRF/browser/trunk/examples/buildbot.cfg.
Oh, and the buildbot community has been very responsive and supportive
at #buildbot - a huge factor in its favour.