[Buildbot-devel] Forcing on a given buildslave

[Pierre Tardy]

>
>
>
> 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 ;-)

Regards,
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20120903/da1c59c5/attachment.html>