On Wed, 2011-09-28 at 22:26 +0100, Max Bolingbroke wrote:

Hi Hackagers,

I've written a rough-and-ready documentation building service for the Hackage 2.0 effort. It is functional enough to submit build reports and build documentation for a few example packages on my local Hackage instance.

Duncan: please review+commit! I also had to make some small changes to cabal-install that should go into the Cabal repo.

Cool, thanks. That was quick! I only just got back from Tokyo. Also got your note about the patch to avoid applying.

Comments/suggestions welcome. There is one major known flaw in that the invocation of "cabal install" performed by the builder is not sandboxed. So arbitrary user code runs with the same privileges as the documentation builder itself. I guess the best solution to this is a chroot (to restrict the writeable part of the file system)+timeout?

Yeah, I think this is probably best solved by sys admin stuff rather than trying to build anything sophisticated into the client itself. Someone setting this up on a system would want to use some kind of sandbox, either a vm, a chroot, SELinux policy or whatever else their system provides. We should probably just provide a big fat warning and pointers to documentation on various sandbox/container technologies. Duncan

On Wed, 2011-09-28 at 22:26 +0100, Max Bolingbroke wrote:

Hi Hackagers,

I've written a rough-and-ready documentation building service for the Hackage 2.0 effort. It is functional enough to submit build reports and build documentation for a few example packages on my local Hackage instance.

Duncan: please review+commit! I also had to make some small changes to cabal-install that should go into the Cabal repo.

Ok, all committed now except for one of the cabal-install patches. I did some rebasing of some patches, so you'll want to blow away versions of the patches you sent me, and pull from upstream. You can check first by doing a darcs push --dry-run. Blow away anything local that looks suspicious. Despite your efforts, the mirroring client still doesn't share much infrastructure with the build bot client. In the last few days I've changed all the http get/put/post and http error handling code in the mirror client to make it robust to various kinds of errors. I'm sure that much of it can be shared though. I've not yet applied the cabal-install patch that makes the haddock options available via cabal install. I'm not sure about making them available directly as install commands since it's not clear from context what e.g. cabal install --css means, plus we're likely to get name clashes. I'll have a think about alternative approaches. Alternatively, could the build bot just run each phase separately? As in cabal install --only-dependencies; cabal configure; cabal build; cabal haddock; cabal-install --only Solving the install/haddock command line UI issue would be good, but perhaps we don't have to right now... Or maybe it's better to be forced to find a solution now. :-) Anyway, all good progress. And I've been talking to people about potential public hosting for a testing server. Duncan