[Buildbot-devel] Enable force build of arbitrary revision

[Brad Hards]

On Friday 21 October 2005 11:16 am, Brian Warner wrote:
> > 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?
KDE isn't all that broken, mostly. I'm actually building the most unstable 
library branch anyway (see http://www.englishbreakfastnetwork.org:8010), so 
other branches don't worry me too much.
The problem is that building takes resources (eg download bandwidth, CPU time 
that would otherwise be available for more useful builds), so I'd like any 
developer to be able to use it, but not the public.

> > 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?
I do want to allow some people to force builds. Just not everyone.

> 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).
For IRC, it would probably be enough to verify an authenticated nick. Jabber 
would be nice too...

> 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.
For me, anonymous users can view, and authenticated users can force is enough. 
So "allowForce=True" would become "anyone can force", and "allowForce=false" 
means only authorised users can force, with a default list of None.

> "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.
Will have to take a look. Didn't realise it was so complete.
HTTP upload would be nice too though....


> 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).
Maybe later....

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://buildbot.net/pipermail/devel/attachments/20051021/2274fe93/attachment.bin>