[Buildbot-devel] Is extending getChoices method of ForceSched/ChoiceStringParameter to support returning deferreds a good idea?

[Greg Wolgemuth]

My current pair of use cases are:

Querying SVN/Git to generate a list of branches, so that branch selection
for forced builds isn't an error prone "type the case sensitive jargon then
wait" process. It might not seem like that big a deal, but our dev team has
a "branch early, merge quickly" mentality and being able to click their way
to the branch they want would be a boon.

Querying our agile issue tracking system for a list of open
stories/bugs/tasks to assign to the build.

My current plan is to modify 'buildForceContext' to be decorated with
@defer.inlineCallbacks; then after buildForceContextForField is called for
all fields, iterate over the fields again to yield any deferreds from
getChoices. Then the 'content' method can simply yield the
buildForceContext method.

I'll try making a github repo and pull request later today.


On Thu, Mar 7, 2013 at 11:17 PM, Jared Grubb <jared.grubb at gmail.com> wrote:

> What kind of external data would you like to use? Is it something
> relatively static (values stable and can be cached, but may change at
> certain events [slave connect, build complete, etc]) or truly dynamic
> (values in constant flux and must queried fresh every time)?
>
> One application I really want to use here is the ability to collect
> configuration info about buildslaves and allow a build to run on a slave
> that has that ability. For example, you could imagine that you have a "OS X
> 10.8" builder, but each slave might be any of {10.8.0, 10.8.1, 10.8.2, ...}
> and there are times when you really care which one you use ... but setting
> up a completely separate builder for those situations is overkill.
>
> So rather than just "pick a slave", I want to be able to "pick a slave
> that can/has ___" and have a dropdown box autogenerate the "can" values as
> the union of what all the slaves currently can do, and dispatch to a good
> one.
>
> Jared
>
> On 7 Mar 2013, at 14:30, Greg Wolgemuth <gwolgemuth at magmic.com> wrote:
>
> I just saw Jared Grubb's work in (
> https://github.com/buildbot/buildbot/pull/641) and was immediately
> interested. I have several use cases for dynamically populating lists on
> the Force Build screen.
>
> Several of my use cases involve generating these lists from data external
> to BuildBot. My first thought was to alter the call chain to getChoices to
> support getChoices returning a possible deferred. But I'm worried about the
> context of buildForceContext in status/web/builder.py. Does this only
> trigger when the user loads up the builder page itself? Would invocations
> of getChoices/buildForceContext need to be parallel, to prevent page
> latency from getting too high (especially when viewing the "all builders"
> page)? I don't want unnecessary, expensive calls to external systems
> slowing down BuildBot too much.
>
> I'd be happy to write up a pull request for this if it sounds like a good
> idea.
>
> -
>
> Gregory Wolgemuth
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
>
> http://p.sf.net/sfu/symantec-dev2dev_______________________________________________
> Buildbot-devel mailing list
> Buildbot-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/buildbot-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20130308/fc6b3014/attachment.html>