[Buildbot-devel] Having one builder pause other builders on the same buildmaster

Philippe McLean philippe.mclean at gmail.com
Tue Sep 27 16:42:13 UTC 2011


You can use schedule triggers (the completion of a build launches dependent
builds), and you can use locks (only one build of a set is permitted to run
at one time).

By composing these elements you can robustly address build dependencies.

On Mon, Sep 26, 2011 at 5:16 PM, Matisse Enzer <menzer at apple.com> wrote:

> We have a bunch of git repos for a collection of Ruby gems that all send
> change messages to a single build master. We have arrange a cascade of
> triggered builds with a dependency graph roughly like this:
>
>
> digraph G {
>        backup_service -> file_system;
>        compiler -> setup;
>        file_system -> setup;
>        linker -> compiler;
> }
>
> So the "backup_service" gem depends upon the "file_system" gem, and the
> "file_system" gem depends upon the "setup" gem, and so on.
>
> A success build of "setup" triggers builds of all the components that
> depend on it, in this example that would be "file_system" and "compiler"
>
> The trouble is, a  build of "setup" can take 20 minutes, and we would like
> to hold all pending changes on the other components until that build
> finishes. That way if a new version of "compiler" needs the new version of
> "setup" buildbot will not build "compiler" until "setup" is done and
> available to the build slave(s)
>
> Is this reasonable to do?
>
> A more general question is how to best handle projects such as like which
> (like Rails) have many interdependent components hosted in different
> repositories. We want a cascade of builds and tests when something changes,
> but we do not want false failures as upgrades ripple through the code base.
>
> -M
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> 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/20110927/d5f05365/attachment.html>


More information about the devel mailing list