<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 01/02/2010, at 22:19 , Simon Marlow wrote:</div><br><blockquote type="cite"><div>Correct me if I'm wrong, but your buildbot runs entirely on the client and is designed to do a (configurable) build and email the results, right?<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div>Yes, that's all -- it's just something that I hacked together. The potential to use Ian's new buildbot for DDC as well makes me extra-keen to help with the development / testing. (And I'm guessing Neil feels the same for his own projects).</div><div><br></div><div>The only thing that makes me wary is the potential for "complexity inversion", where the "configuration language" just becomes a poor simulacrum of the implementation language -- which is where my own code seemed to be going. Approaching it as a DSL / framework / library should help ward this off though.</div><div><br></div><div><br></div><div><blockquote type="cite"><div>What we're trying to do is more like BuildBot: there's a server where all the configuration happens, and the clients run a very thin program that simply takes instructions from the server, executes them, and sends back the results.<br><br>We want to handle an unreliable connection between server and client, which is what BuildBot doesn't do. We also want the server and client to be restartable without losing any state, as far as possible.<br><br>The key concept is that the build instructions are written in a Haskell DSL on the server, e.g.<br><br> do<br> r <- buildstep "get repo" "darcs get <a href="http://darcs.haskell.org/ghc">http://darcs.haskell.org/ghc</a>"<br> if failed r<br> then return something<br> else do<br> r <- buildstep "boot" "sh boot"<br> ...<br><br>but this needs to be restartable if the server goes down, so the idea is that we use a caching monad where the results are saved and the instructions are re-run from scratch to generate the next build step, using the technique that originally appeared in WASH. I think this is a pretty cool way to write a build server - we get to write our build instructions in Haskell, but we keep the advantages of stateless communication with the client.<br><br>This part is all independent of GHC and could easily be put into a library. I expect we'll have a library of build instructions that are specific to GHC too, and it makes sense to separate those out.<br></div></blockquote></div><br><div>Sounds good to me!. Yeah, such a framework sounds easily reusable. Hopefully it will also have a story about graceful exception handling. For example, if my script tries to fetch the darcs repo but <a href="http://code.haskell.org">code.haskell.org</a> is down it just dies. It'd be great to have a combinator for "if you can't connect then wait 10 mins then try again, up to 5 times, before giving up for today."</div><div><br></div><div>Ben.</div><div><br></div></body></html>