CI
CI, or continuous integration, is the process of merging code into a shared mainline version. For us this means merging our local changes into the remote repository after checking for errors.
I aim for three checks in CI,
- the code is correctly formatted according to an autoformatter,
- the code is correctly structured, there are no syntax issues, and there isn't any unused code,
- the code passes all the tests.
Which I'll refer to as the formatting, linting, and testing stages of CI.
Activating CI resources
We need compute resources to run these stages, so lets make use of
Gitlab-CI's shared runners by adding shared_runners_enabled = true
to the infrastructure/gitlab.tf
file (note only the relevant
resource is shown),
resource "gitlab_project" "tozo" {
...
shared_runners_enabled = true
}
with ...
representing the existing code. This allows us to write a
.gitlab-ci.yml
file that runs CI jobs on every push to the remote
repository master.
It is also useful to schedule jobs e.g. the dependency checker, to run
periodically via this addition to the infrastructure/gitlab.tf
file,
resource "gitlab_pipeline_schedule" "tozo" {
project = gitlab_project.tozo.id
description = "Schedule checks against the codebase"
ref = "main"
cron = "0 9 1 * *"
}
which will trigger the check at 9am on the 1st day of each month, see crontab guru for more.
Remember
Remember to re-run
terraform apply
ansible-vault encrypt terraform.tfstate --output=terraform.tfstate.vault
after making changes to the infrastructure.