<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Le mar. 22 mars 2016 à 22:07, Georges Racinet <<a href="mailto:gracinet@anybox.fr">gracinet@anybox.fr</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi there,<br>
<br>
After a long time during which we couldn't do much more than maintaining<br>
our instances, we (Anybox) are considering migrating our buildbots to Nine.<br></blockquote><div><br></div><div>This is good news!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Among the many things that I've developed for our needs [1], there is a<br>
rather complete capability system [3], and hence I must decide whereas<br>
it's worth porting it or not [4]. I know it's a fairly common need that many<br>
development shops have been doing in private or almost, but it's not<br>
obvious to me what is freely available (for Nine) on this topic.<br>
<br>
<a href="http://trac.buildbot.net/ticket/3120" rel="noreferrer" target="_blank">http://trac.buildbot.net/ticket/3120</a> does not get to a conclusion, and I<br>
couldn't find much on it in a quick search of recent messages on this<br>
list. Maybe I missed something else ?<br></blockquote><div><br></div><div>Since that, I figured Workers have properties, which can be used in NextSlave callback in order to match any capability.<br></div><div>I think it would be much better to have something in the core, not depending on having the users writing a capability specific nextSlave/nextBuild callbacks.</div><div><br></div><div>Actually, there are two aspect in the capability problem. The static and the dynamic.</div><div><br></div><div>1\ Static problem is the easiest. It looks this is what you implemented already (and metabuildbot has in a smaller extend):</div><div>- One part of your config describe the workers, and their capabilities</div><div>- Another part is describing the builders, and their required capability.</div><div>The system will then automatically configure which worker to associate to which builders.</div><div><br></div><div>2\ The dynamic problem. Slave are chosen at the start build phase.</div><div><div>- One part of your config describe the workers, and their capabilities</div></div><div><div>- Another part is describing the builders, and their required capability.</div></div><div>- Each build requests can require an additional set of capabilities, which can restrict more the set of slaves which can run them.</div><div>In order to implement that efficiently, one will have to mess around inside the buildrequest distributor code, which I can understand looks scary.</div><div><br></div><div>I am not sure which one you are needing/implementing.</div><div>I think it is fine that you only implement 1/ if this is what you need, but I would like that the design opens the door to implementing 2 without need to rewrite everything.</div><div><br></div><div>Regards</div><div>Pierre</div></div></div>