bzr_buildbot.py: bzr needs a BzrPoller

some useful links:

• http://bazaar-vcs.org/ConfiguringBzr
• http://bazaar-vcs.org/ConfiguringBzr#head-8393d9ddb7576e6ec586051325e1bede11e1d151
• http://bazaar-vcs.org/BzrPlugins
  • in particular the CIA and email plugins

I think the path here is to create a Bzr plugin for buildbot, distributed with buildbot, and then provide instructions for enabling the plugin from within a Bzr repository.

some more notes:

~/.bazaar/locations.conf:
[/home/warner/full/path/to/tree]
post_commit = bzrlib.plugins.buildbot.sendchange
buildmaster = host.example.com:12345

post_commit is a space-separated list of fully-qualified function names. Each will be eval()ed in a way that calls sendchange(branch, revision_id).

~/.bazaar/plugins/buildbot.py:

def sendchange(branch, revision_id):
    pass

However, this hook doesn't seem to be triggered when I push a change in via something like bzr push sftp://host/home/warner/path/to/repo. I don't know if push triggers commit or not.

I spent some time chatting with <lifeless> on IRC today. Some things I learned:

• most of the existing access schemes (file, sftp, http) do not run any code on the "master" host at all. Any post_commit hooks would be run on the client machine. This could be made to work, but you'd have to have buildbot and the hook plugin installed on all developers machines, which would be a nuisance.
• the "Smart Server" that is under development now will make it much easier to run code like this on the central machine after each commit.
• he recommends using 'import bzrlib' to get at things like 'bzr revno', rather than spawning 'bzr' as a shell command. He says they try hard to maintain API compatibility.

So I think we need to write a BzrPoller? first, and defer writing a hook script until after the "smart server" is implemented. The only thing we could implement now (using post_commit=) would be too much of a nuisance to deploy.

some comments from an IRC chat a few weeks (months?) ago:

<spiv> warner: that seems ok, but I think you can make the common case of no
new revisions faster by first checking b.last_revision() [01:41]
<spiv> warner: and really you want to use revision ids rather than revnos, in
case someone e.g. did an uncommit.
<spiv> warner: also, if you do b.lock_read()/b.unlock() around the whole
thing, it should be a little faster because it will be able to cache some
things. [01:42]
<spiv> warner: also "# NOTE: b.revision_history() does network IO, and is
blocking." is a strange comment, given that that's true of the previous line
too, but you didn't comment it :)
<spiv> (and of the line before)>
<spiv> warner: "# branch= ?"... that's just self.location. [01:51]
<spiv> warner: "# revision= ?"... either the revno or the revision ID,
whichever you prefer. [01:52]
<spiv> warner: No other comments spring to mind... if you have specific
questions, let me know.
<lifeless> whats revision_history ised for? [01:59]
<lifeless> if its to get the revno, use get_revision_info, its cheaper
<spiv> lifeless: it's to get the all the new revisions since the last poll
<lifeless> isn't that update ? :)
<spiv> Presumably so that it can send updates or whatever about them.
<spiv> Well, I assume the buildmaster doesn't actually need or want to have an
actual checkout or branch.
<spiv> warner: please feel free to chime in here :)
<lifeless> if its just caching metadata about where the branch got to; sure.
                                                                        [02:03]

removed the obvious MultiService? bug

not making enough progress on this one, bumping it to 0.7.8

changes to get it work (in simplest scenario -- single branch)