[opam-devel] Container based Travis CI service

[Michael Grünewald]

> On 03 Sep 2015, at 19:34, Anil Madhavapeddy <anil at recoil.org> wrote:
> 
> Thanks for posting this to the list, Michael.  We definitely need to do
> something about Travis, since the legacy infrastructure is failing regularly
> with network timeouts.

I am completely new to depexts so let me describe the problem in
few words, just to be sure I got it right: the opam-repository
has a Travis CI script which will build each PR (typically,
a package update or a new package) and depext (the opam plugin)
kicks in to install missing dependencies living outside the
opam world, typically using the host OS package manager.

Then the setup I wrote about is definitely not a replacement
tool for the depext plugin, at least for the opam-repository.
For a “normal” repository – whose test suite does not need to
install arbitrary packages dynamically – the setup I describe
can easily me mimicked to switch to the new container infrastructure,
also taking advantage of caching!

I had some thought about the special case of the opam-repository
and it looks like we will have a hard time unless some amenagements
are made to the Travis infrastructure.  The most promising
solutions I could figure out involves the fakeroot command
or a tool similar to strace to trace system calls, but I
am not sure how good this is supported in Travis CI containers.
I am also not a Linux user and I am therefore not familiar with
the intricate details of the fakeroot command but at a first glance
it seems, that we could setup a new, container-based, continuous
integration environment according to the following lines:

1. Installation step:

  1.1 install all Ubuntu packages needed by
      all packages in the opam repository

  1.2 install all the needed versions from OCaml using
      opam; be sure to cache this!

2. Test step for package *foo*

  2.1 acquire the list of depexts for *foo* and add it
      ocaml, opam and maybe some other essential packages.

  2.2 query the package database to obtain a list of all files
      owned by packages in the list prepare in the
      previous step; be sure to include config files, if
      appropriate.

  2.3 prepare a fakeroot environment replicating the files
      listed in the previous steps, with hard links.

  2.4 jump in the fakeroot environment and test the package

Of course, the point of steps 2.1-2.4 is to hide packages
not found in the depexts spec from the scope of the build,
to ensure that this list is comprehensive.

An alternative to 2.3-2.4 would be

  2.3’ test the package under strace or a similar
       facility in Ubuntu

  2.4’ confront the results of strace with the list of
       authorised files found in 2.2, if we see that the
       test accessed other files, then reject it.

If no strace alternative is easily usable in Travis CI,
we could run the build script with customised open(2) and
stat(2) functions, to throw an error when a forbidden file
is accessed.  This relatively easy to do, using the
LD_PRELOAD mechanism, as illustrated here:

  http://stackoverflow.com/questions/6083337/overriding-malloc-using-the-ld-preload-mechanism


I think the ease of implementation of these solutions are,
from the easier to the harder:

  1. use a strace-alike mechanism
  2. use customised system calls open(2), stat(2), and
     all their cousins
  3. build a suitable fakeroot environment

Best,
Michael