[ANN] dommage, Dockerising the Mirage CLI

Community
,
1

All;

I’ve just pushed a first cut at a tool, dommage(*), that wraps the Mirage command line tool so that it operates within a container. This should mean that:

  • you can cache the OPAM build artefacts in the container image which speeds up local builds;
  • by publishing said build container image, you can re-use it in Travis builds, speeding those up considerably; and
  • you can now easily test build -t xen targets on OSX.

Likely gotchas include how I handle UID/GID mappings between the host, the OPAM CI build container dommage derives containers from, and those derived containers; and the inability to set the compiler version (pegged at 4.04.2 once the current container build completes).

I would welcome feedback, positive or negative!

(*) Yes, the name is a deliberate attempt at a French pun by a non-French speaker. So please tell me if it’s inappropriate, misspelt, or otherwise makes no sense! :slight_smile:

3 Likes
2

This is cool! I haven’t looked at it in detail, but I was wondering from the README: Is there a reason why there are dommage build, dommage configure, etc commands, rather than dommage whatever = do whatever with miragein the mirage container, for an arbitrary set of arguments?

3

Only that there are dommage whatever commands where mirage whatever
doesn’t work (init, destroy, publish, run), and I also chose to
make the dommage configure command also run make depend after mirage configure.

But I guess I could probably make that logic a bit neater so that the
non-overridden cases just pass through…
(Are there any mirage commands missing particularly?)