Basic GitLab CI configuration

Ecosystem
25

After a long ci-golfing adventure (83 tests), I got a .gitlab-ci.yml file that I think is reusable and useful for small projects / libraries:

Features:

  • It is project-agnostic, so it should work unchanged for your own (simple) projects.
  • It caches the opam dependencies.
  • It builds the project, runs the tests and builds the documentation.
  • Several compiler versions can be tested in parallel.
  • It provides an easy way to upload the documentation as “Gitlab project Pages”.

CI times are satisfying: on very small libraries I observe a 11mn job time on the first run (or when cleaning the opam cache), and 2mn job time on following runs.

The expected usage-mode of this CI configuration is that you copy it in your own project. If you find that you need/want additional features, ideally you would try to write them in a project-agonistic way and contribute them back to the example repository.

This configuration does not use @smondet’s trick of generating a docker image on the fly. I think this would be an excellent idea to get more reliable caching, but it is too complex for me and I don’t see how to do it in a maintainable and project-agnostic way.

Current status

I wrote this CI configuration over the week-end, and have not used it much. I expect it to keep evolving somewhat before it stabilizes. Feedback from other people trying to use the configuration would be warmly welcome.

Aside on _build caching

I also implemented caching of dune’s _build data, inspired by the data-encoding example of @raphael-proust. I don’t need it for my small projects (dune build is 3s, compared to 1m setting up the Docker image), but I thought it would make the CI configuration scale better to larger projects.

When I tested this CI configuration, I discovered that caching the dune _build data does not work as well as I had expected. (Tracking issue: dune#4150).

I can tell because I am asking dune to tell me about what it is rebuilding (dune build --display short). I suspect that projects that cache the _build data without logging what dune (re)builds are also not caching as much as they think they are.

(But then maybe the use of a fixed-compiler OPAM image, as data-encoding is using, solves the issue.)

official CI template?

I considered submitting this CI configuration as an “OCaml Gitlab CI template” to go with the official list of “blessed” CI templates in the documentation. But reading the Development guide for Gitlab CI/CD templates convinced me that my CI configuration is nowhere ready to serve this role.

Gitlab developers apparently expect that users will be able to “include” those CI templates by pointing to their URL, and then tune it for their own use-case (without modifying it) by performing some (unreasonable?) inheritance tricks using whatever those configurations offers as abstraction/inheritance/extension/overriding mechanism. Let’s just say that this is next-level CI configuration writing, and that my script is not ready for this.

9 Likes