Move website builds to GitLab CI
I would like to move the build and deploy of websites from binary-factory to GitLab CI. I did some testing in a fork already, deploying to my personal server.
My motivation is to eventually get merge request testing, and maybe even staging deploys so that we stop doing direct "git push -> production". But those are obviously "stage 2" features, first we need to carry over the current binary-factory functionality :)
Proposal:
- The website repositories won't have a .gitlab-ci.yml, rather the config will be in a sysadmin-only repo (binary-factory-tooling?).
- We have scripts that periodically set repository settings, we should make them manage the "alternative CI yml path" setting too (this is something we also need for the KDE software CI anyway).
- Use two CI jobs+stages, one to build and another to deploy. This lets us (later) run builds on merge requests, branches and forks, while doing deploys only on the master branch.
- The ssh key to do the deployment can be passed as a CI variable. Several security features are available here: the variable doesn't propagate to forks, can be configured to only apply to "protected branches", and I think can be configured so it's available only on the deploy job and not the build job.
- Alternatively, we could run the deploy step on a dedicated runner that has access to the key. But I think this is harder to get right. Our sync script would need to change the runner configuration to only run on certain repos (on the gitlab side; I didn't even check if there's API for that), and we can't use fine-grained keys (see below).
- A .yml file can be reused by multiple repos, by setting
deployserver
anddeploypath
as CI variables too. That way we get a similar setup as now, with many websites reusing eg. hugo.pipeline. - We need a separate builder to avoid the current multi-hour CI queues blocking website deploys. Maybe we can use dalca2; website builds probably don't take much advantage of multiple cores so it should be enough resource-wise.
- Bonus: authorized_keys on edulis/nicoda/etc can be configured with forced commands so that the ssh key can only run rsync and only in a certain directory. Then we can use different keys for each job, and lock down at a fine-grained level what each is allowed to do.
Any comments/objections on the general approach? We can discuss where to start and exact steps later.