[ocaml-platform] OCamlot

[Wojciech Meyer]

Hi,

Without reading the full thread, as I am at work now.

I'd suggest two important points:

1) writing up, what kind of permutation of os, archtiectures,
compilers,packages we want to test, which are must have, which are
less irrelevant. Maybe at some point we will find that some of the
packages will be more important on the different architectures, so the
list have to be prioritised to schedule jobs efficiently.
2) what other platforms do, what Ruby for rvm does, and Python with
pip does, and maybe what Haskell and cabal does - with the interpreted
languages the requirement of testing on a different architecture is
somewhat lifted.

These are fairly obvious, but once we know it, we probably in a better
position to asses what kind of resources we need..
Wojciech


On Thu, Feb 14, 2013 at 11:15 AM, Sylvain Le Gall
<sylvain+ocaml at le-gall.net> wrote:
> 2013/2/13 Anil Madhavapeddy <avsm2 at cl.cam.ac.uk>:
>> On 13 Feb 2013, at 22:42, Anil Madhavapeddy <avsm2 at cl.cam.ac.uk> wrote:
>>
>>> 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.
>>
>> It's also worth noting the difference in execution speeds for adopting a copy-on-write approach.  We  need to test 300+ packages (which will grow) across 3.12.1/4.00.0/4.00.1/4.01.0dev and experimental compiler branches, ideally without recompiling the compiler for each package.  If a package fails to build on a fast architecture (x86), it should immediately be dropped from a slow one.
>
> Humm, to be honest, I will:
> 1. limit the number of compiler version (4.00.1 or 4.01.0 when it will be out)
> 2. limit the number of packages
>
> I think 300+ packages in OPAM term is the number of tarball. Let's
> just take either the last one or the last one that we were to build on
> all platform. I don't want to have OUnit 1.1.0 and 2.0.0...
>
> Concerning Travis/Jenkins/whatever, I think we should consider this:
> - just create a shell script that do the job and don't interface
> strongly with the build system in the core job
> - most of the builder I know, can have some restriction, esp
> concerning accessing the network. This is not always true but we
> should try to avoid downloading stuff
> - create a big git repository that basically contains an opam
> repository + the builder shell script and do the job inside it
> - try to output the results of tests/build in a "common test result
> format" (either TAP or JUnit)
> - consider that most platform don't allow you to install stuff that
> are 3rd party (e.g. C libraries that comes with the OS, like libzmq0
> or libfoo.so.XX), I don't think we should build them on our own (let's
> focus on OCaml)
>
> I think this can be done independently of the platform we use for
> continuous integration, when we will have gained some experience, we
> can enhance the process for a specific/preferred platform.
>
> I start to play quite nicely with Jenkins and I think you don't have
> to build any plugin to make it works:
> - use a matrix project to build on all platform, have a first step on
> 1 particular platform that need to succeed (integrated, I use it)
> - use a shell script to start the build, no maven, no ant (I use it)
> - ...
>
> I will look at memory issue with java worker... Let's say I have a
> couple of Java specialist sitting next to me. I will need to run one
> on my RPi...
>
> Regards
> Sylvain
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform