CI with more features

With some work, we can hope to do away with the cado-nfs-ci jenkins server entirely, which will remove a lot of dirty stuff that happens under the hood. (and which is hard to maintain)

Things that we already have or would like to have with this MR.

• routine checks with latest gcc
• routine checks with latest clang
• routine checks with latest icc
• coverage tests (see here). This basically works, except that we have fairly limited visibility on the coverage reports. What we have (here for the current branch ci-more-features is:
  • a way to download the html coverage report as a .zip file (e.g., following this link)
  • a gitlab badge that is adapted to the current branch and reproduces the overall coverage ratio: (for this MR: ; for the master branch: . Note the poorly documented syntax regarding how to access the badge for the MR pipeline.)
• a leaner test suite! Clearly, we're testing too many things, often because some cases are multiplied. We're down by a good third of the previously existing tests, at this point.
• routine testing on several fixed versions of fedora and debian (should be rather trivial). We might do these checks with gcc always, and optionally with clang on fewer versions, for instance.

The following things are also desired, BUT we can't do them with docker executor on runners.

• routine testing on arm32 hardware. I prefer to disable it. It works, but takes three hours. I might re-enable it at some point, but as long as I'm tinkering with the ci/cd infrastructure, it really gets in the way.
• routine testing on freebsd. This now works, using the tailor-made tanker script!
• routine testing on openbsd we don't know how to do this (yet) in a way similar to what we do for freebsd
• routine testing on osx

It's not clear that all of this should be done at every single commit, but pending the cleanup of our hefty test suite, I'd advocate to do all that every time.

Presently, the first stages of the test suite are in charge of creating docker images, push them to the project registry on gitlab.inria.fr, and eventually re-use them for further compiles. In the long run, this might be beneficial if an image is really reused many times before it has to be refreshed. However, it's not clear that we'll keep this approach eventually.

A side-effect of the previous remark is that the runners that prepare the images must run docker themselves. There are various ways to make this work. I know of the following:

• use privileged runners (a.k.a. root), and docker-in-docker images. I really don't like the idea.
• use runners with the shell executor. Didn't consider it really, but should work.
• use runners that are configured to bind-mount the docker socket of the host. (see there).

It seems to me that the latter option is better, and I've adapted the configuration of all our docker runners to work that way (I probably forgot some of them, though).