[Buildbot-devel] Retrieving build results

[Joel Becker]

On Fri, Nov 25, 2005 at 11:55:45AM +1100, Chris Leishman wrote:
> Obviously using buildbot for a regression testing system is great, but I
> would actually like to use it produce our release builds and snapshots.
> Obviously this means I need to get the built product somehow...
> 
> Currently I'm doing this by adding a build step to calculate a new
> version number and copy the build products to a publicly accessible location.
> But this is a bit of a problem if I want to allow builds on any branch
> or 'try' builds, since the step will end up creating a release from code
> that wasn't actually from the main code line.

	We consider RPMs to be our "built" product right now, though
debs would work as well.  What I do is have the RPM build destination be
on NFS.  I then have the "release" version of the RPM (the -1 part of
the RPM or deb) reflect the Subversion revision.  I use a script,
svnrev.guess, that gives me the value.  The script is at:
http://oss.oracle.com/projects/oracleasm/src/trunk/svnrev.guess
	Here's how it works.  If the branch being built is not a release
tag, it gives a "release" version of 0.<revision>.  If the tree is
modified (as it would be for a "try" build), it gives 0.<revision>m.  If
the build is a release tag ("<repository>/tags/<project>-x.y"), it gives
a release of -1.  If the tag has been updated (small packaging fixes),
it ups that number by traversing "svn log" until it finds the tag's
creation.  Because we can't add new tags to the Any scheduler easily,
tags have to be build by using an explicit request, but that's OK.  It's
a release, after all.
	This gives us two properties.  When looking at the built
packages, any package with a "release" of -0.anything is not an official
release and can be ignored.  Second, if we give out a particular
revision to a tester, we can be assured that the next revision will sort
correctly for "rpm -U" or "dpkg -i", and the release (-1) will sort
correctly as well.
	Let's try an example to clarify:

A regular commit:
    # svn co http://myproject/trunk myproject
    # cd myproject
    # hack; hack; commit
    Committed revision 200
        (Buildbot creates myproject-1.0.4-0.200.i386.rpm)

A "try" build of a modified tree:
    # hack; hack;
    # buildbot try ...
        (buildbot creates myproject-1.0.4-0.200m.i386.rpm)

Working on a branch:
    # svn switch http://myproject/branches/temp # changes aren't
                                                # appropriate for trunk
    # svn commit 
    Committed revision 201
        (Buildbot creates myproject-1.0.4-0.201.i386.rpm)

Tagging a release:
    # svn cp http://myproject/trunk http://myproject/tags/myproject-1.0.4
    Committed revision 202
        (Use Waterfall to force a build of tags/myproject-1.0.4 ->
         Buildbot creates myproject-1.0.4-1.i386.rpm)

Joel
        

-- 

"I don't want to achieve immortality through my work; I want to
 achieve immortality through not dying."
        - Woody Allen

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127