Start using GitLab CI for non-ISO jobs
As per our roadmap session made during Summit 2020.
There are many ideas in the air, let's use this issue to gather them and start with something.
Potential candidates
Public stuff, no credentials required
- #16712 (closed)
-
check_PO_master
(Jenkins job definition,check_PO
builder), that runslint_po
, which itself usesi18nspector
:- It would be nice if translators could see the status of the CI check.
- This would allow us to run whichever version of
i18nspector
we want, e.g. to benefit from new checks we've requested after translation mistakes caused bugs in Tails.
-
Checking PO files on any branch, currently done in
features/po.feature
: same ascheck_PO_master
, it would be nice to be able to choose the version ofi18nspector
we're using -
Check PO files with
msgfmt
. We'll see if it catches errors thati18nspector
misses: if not, we should consider dropping themsgfmt
check. - Check "meta date" directives in PO files
- WhisperBack's unit tests (added to our Cucumber test suite via tails#16936 (closed), but arguably this would be better suited for GitLab CI)
- The subset of tails#15330 that can be done without booting Tails
- #17775
- tails#17940
- Linters:
- Rubocop (tails#17646 (closed))
- ShellCheck (tails!190)
Sensitive stuff
- #17364
- Run
gitlabracadabra
fromtails/gitlab-config
, e.g. in dry-run mode and then a step to manually confirm and run the deploy. - Issue triaging with
gitlab-triage
(currently run manually by intrigeri) - Weblate integration scripts (could improve reporting, collaboration and overall design) - puppet-tails!31 (merged)
Current conclusions
- We don't need the registry as long as we don't need store any built container images in it. (We have no registry at the moment.)
- Using custom built images stored in a registry can help improve the speed and the robustness (reproducibility, trust, etc) of the CI, if/when those become a problem.
- For the simple non-ISO jobs we consider here, the Docker runner should work.
- In production we'll want to trust sufficiently the runners: humans make decisions based on CI output. Possibly during initial dev work we can use less trusted runners, and tell developers they shall not trust the results (yet).
Next steps
- Let developers try the CI out and gather feedback.
- Sysadmins: make the GitLab CI runners into production.
- Build our own Docker images and use our own registry.
Clean up once GitLab CI is in production
- tails#17992
- #17776
-
remove the call to
bin/sanity-check-website
inbuild-website
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information