[Buildbot-devel] Forcing on a given buildslave

[Jared Grubb]

On 3 Sep 2012, at 08:24, Pierre Tardy <tardyp at gmail.com> wrote:

> Thank you, then I'd like to introduce it.
> 
> The use case would be to help debug if a slave goes wrong, or to
> validate that a new slave performs as expected, not to make it a normal
> operation of buildbot should be to distribute builds among all slaves
> registered for that builder (in our setups it's an automatic process
> based on slaves capabilities).
> Setting a up a testing buildbot and have new or problematic slaves
> attach to it is of course an option, but it's cumbersome. I've setup
> one, but I've never used it apart for experiments about buildbot itself.
> 
> I used to believe that maybe setting the 'buildslave' property would
> force on a precise slave (if available). That proved out wrong, but
> wouldn't it be a simple way to present it ? The corollary would of
> course be that a rebuild always takes place on the same slave.
>  Hi Georges,
> This is also a feature that I was needing. I can see 3 use cases in my own environment:
> 1- The user want to launch a build in a slave that is network wise near him. We have some collaborators that have slow interconnection, and downloading 300+MB build artifact takes a lot of time.
> 2- We have some slow machines, and fast machines, and want to prioritize some builds by giving them faster machine, while other builds can get slowly processed by slow machines
> 3- Buildbot devs want to reproduce strange stuff that happens only on one slave (your usecase)
> 
> We have an implementation in our internal tree that I'm wanting to upstream in the next few weeks.
> From the user point of view, the basic idea is to give a new argument to nextSlave, which is the buildrequest.
> Then you could get a "forceOnSlave" property in the buildrequest, and return the slave, if it is available for a build.
> 
> From an implementation point of view, this is more complicated, as the slave is chosen before the buildrequest, But if you inverse this choice, you may end-up choosing a buildrequest
> that has no slave candidates. So we basically keep the order, but annotate each unclaimed_request with the name of the potencial slave (using nextSlave), instead of just choosing one slave,
> and then call nextBuild on the unclaimed_request that have a possible slave.
> 
> I need to cleanup the code, write more tests, and figure out how to support the old/current nextSlave API before upstreaming this
> If you are motivated enough to do it before me, go ahead ;-)

I think it might be possible to swap whether the buildrequest or the slave gets chosen first.

I've been looking at that chunk of code lately to solve another issue in that area. I have 3 buildslaves, and use slave-locks to make sure only one build happens per slave. The slave-assignment code doesnt check for locks before randomly picking a slave ... so I'll have cases where I have two slaves idle, and one or more builds assinged to the busy slave, all waiting on locks.

Jared
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20120903/1ad5c739/attachment.html>