[Buildbot-devel] Enable force build of arbitrary revision

[Brian Warner]

> If the last build was "build HEAD" then the user didn't care what it was,
> just as long as it was recent. A different recent code snapshot probably
> isn't all that important.

Well, the use case I'm imagining here is a scheduler.Periodic that's cranking
out nightly builds, and you want to re-run a build from last week now that
you've fixed something about the environment (and you don't want to run last
night's build for some reason, maybe a large bunch of destabilizing changes
went in and you want to isolate the environment changes from the recent
code). But I'll agree, it's probably not worth working on right now.

> If you do have a specific requirement, then you can possibly 
> extract it from the logs?

Maybe.. it depends upon the VC system. SVN (and most systems that have some
notion of linear-history transaction numbers) is kind enough to report the
revision number it just checked out, so a human could look at the end of the
checkout stdout and figure it out. Darcs (and probably Monotone) is stranger,
and I think you have to ask specifically for a tag or revision of some sort.
For CVS you must know the exact time the checkout was performed or you won't
be able to reproduce it.

> In the longer term, it'd be very useful for the status reporting to have
> some kind of SourceStamp (so the waterfall display might not be "Build
> 113", but would be "Build of 439506", and the email message or IRC
> announcement can tell you what rev it matches.

I'm adding a display of the SourceStamp to HTML and email now, on the
per-Build page. I haven't built an IRC interface to "tell me about historical
build #N" yet, but when I do, it will get the same thing.

I think the Waterfall page (and other show-many-builds-at-once pages) needs
to retain the build number instead of replacing it with sourcestamp.revision,
since build number is the unique index (whereas there may be multiple builds
with the same revision number). It would probably work to have the 'checkout'
text replaced by or augmented with a revision specification.. depends upon
how wide the text ends up being. Oh, and a branch name too. I'll add a TODO
note about this.

> It does concern me - right now I'm keeping an eye on it, and will turn 
> allowForce off if I have problems.

Is it certain branches that worry you, or the overall ability for random
strangers to trigger activity on your buildslaves?

> I'd really like to have some form of "authorised users". I want to expose
> the HTML status display to the world, but I don't want arbitrary users
> hammering my buildslaves.

The allowForce=False argument lets you make this separation in 0.6.6 . How do
you want the capabilities to be split up in 0.7.0?

In the long run, I want to let each kind of status target provide the notion
of an authorized user, and then have some kind of API to indicate which users
are allowed to do what. For the web page, this would be through a login with
username/password on a web page (probably using Nevow). For IRC it could be
through a server-registered nickname, or a cryptographic challenge/response
like the way pyinfo does it (you use an offline tool that knows your private
key to answer the challenge, then paste the response into your IRC session).

I'm concerned about the API that uses this becoming unwieldy, though.
allowForce is currently a one-bit ACL.. adding users creates the question of
what exactly do you want to restrict: user A can force builds of everything,
user B can force builds of "branches/feature/*" but not
"branches/so-broken-it-crashes-the-buildslave", anonymous users can look but
not touch, etc.

> Equally, I'd like to allow "try" patch uploads for authorised 
> users. [ Stray thought - only GPG signed patches matching known good keys?]

"try" already has two means for defining who is allowed to use it (because
the extra patch that bypasses the VC system makes 'try' much more
powerful/dangerous than 'force'). Take a look at the "try" section in the
docs for details.. the first system uses a buildmaster-admin-supplied list of
username/password pairs, and requires the hopeful developer give this pair to
the "buildbot try" command (or put them in a .buildbot/options file). The
second system uses a "job directory" to drop buildrequest files into (over
ssh), and you can then use unix permissions or whatever to restrict who gets
to write into the jobdir.

Signed buildrequest files is a possibility too. It's got about the same
admin/setup overhead as the username/password approach, except that it'd be
safe to use your regular private key instead of creating a new password just
for buildbot work. Spawning GPG is a bit of a hassle though (I have code to
do it for Petmail, but it's kinda big).


thanks,
 -Brian