[ocaml-platform] OCamlot

[Anil Madhavapeddy]

On 13 Feb 2013, at 21:24, Mike Lin <mlin at mlin.net> wrote:
> 
> So therefore we build one from scratch!!??
<snip>
> 
> I'd asked whether options like that were thoroughly considered before deciding to invent one here, and I'm sorry but I haven't gotten that impression so far. 

Yeah, of course.  As with all these things, there's a combination of broad requirements ("does it build on X") with rather specialised ones ("I need to fork this OPAM chroot to build these 3 variants in independent copy-on-write trees").

The question is whether or not a hosted service will hit a brick wall where we simply can't do something we need that's a bit more specialised.  At that point, we'll end up reimplementing all the basic stuff too.

Opamalot is more of a coordination service.  It interfaces with OPAM to get the (non-trivial) package database, version constraints and compiler variants out of it, and comes up with a prioritised schedule of builds and tests that need to be run on different platforms.  Some of these could (and should) run on third-party hosted services such as Travis, just to get some diversity.  Others, however, really require a Xen pool so that more exotic stuff can be done.

For example, the Mirage microkernel should work with a large number of pure OCaml libraries.  Wouldn't it be cool if one of the tests that ran showed you the results of that compilation, and if it fails, what the external dependencies are?  This will never run efficiently on any third-party infrastructure, and it's the ultimate test of portability.

Another one are some of the Citrix/Xen libraries, which require a Xen host to run certain feature tests. This could be hosted on EC2, but probably wouldn't work on Travis (I don't know what hypervisor they use).

Anyway, we're still working our way through what Opamalot should be, but rest assured that it's not an NIH mindset that's causing us to shy away from a third party build service.  When we're growing from nothing as we are, it's nice to have a bit more control over our own infrastructure, and scale out to these hosting services but not be entirely dependent on them.

Note also that Citrix already has an absolutely epic home-grown test suit for Xen that continuously runs hundreds of thousands of functional and stress tests across OCaml code on a large number of physical hosts.  Jon Ludlam's been doing some work on  interfacing OPAM with it.  I'm not entirely sure what that's going to end up looking like, but it's a positive thing :-)

-anil

PS: I was really pleased to see your post about Travis/OCaml/OPAM, as it's been on my list to try for *ages*.  I'm going to give it a whirl this weekend with cohttp!