feat(ci): add GitLab CI config
I have experience with Travis CI, Cirrus CI, and GitHub Actions. The latter two don't support GitLab, and Travis doesn't look reliable to me anymore (their CI jobs were flaky in the past, then the service stagnated for a few years, now they're making some weird moves). That's why I decided to give GitLab CI a try.
This runs all the things that ./check runs, except the Subplot's docgen: it failed to find some TeX fonts, and I gave up on it because docs don't make sense on CI anyway. I can put in a bit more time to get them working if @larswirzenius wants it.
GitLab CI provides 400 minutes per month, which is about 13 minutes per day. With a config from this MR, that's 2–3 builds per day (if no dependencies are changed). Ways to improve:
- join GitLab for Open Source program, which will give us 2,000 minutes/month. But that page talks of "renewals" and stuff, seems bothersome;
- CI spends about 3 minutes (out of ≈6 total) pulling the Docker image and installing packages. We could create our own Docker image and put that either on the Docker Hub or, better yet, GitLab's own Container Registry. The latter doesn't have a pull limit like Docker Hub, and should be faster from inside GitLab. The downside of that approach is that we'll have to maintain an image, rebuilding it when new Rust comes out or important updates hit Debian Buster;
- the image we use, rust:1-buster, is currently 430 MiB in size. We can probably speed up its download if we used GitLab Dependency Proxy. It's a one-line change for our config, but it requires us to move the repo into a group, since Proxy is not available for individual projects. Impact unknown, I don't think it'll save us more than 30 seconds (but that's 8% still);
- run CI only for the
mainbranch and the MRs. This
willmight help save us one build per MR from Lars, since Lars pushes right into this repo instead of a fork. In other words, we'll stop doing two builds for every push Lars makes (one build on the branch, another build for the MR). Update: I now see that this MR says that its pipeline ran in a fork, so perhaps GitLab CI combines builds for the branch and the MR, too.
Docker Hub's pull limit is a ticking time bomb, too: I've no idea how GitLab CI authenticates with Docker Hub to pull the base image, so I don't know which limit applies here. Even then, I don't know the current state of the limit (how many pulls did GitLab do in the last 6 hours?). It's hard to tell when we'll start hitting those limits. Again, moving to GitLab Container Registry should spare us from this.
Fixes #105 (closed).