Start using GitLab CI for non-ISO jobs
As per our roadmap session made during Summit 2020.
Next steps
-
Let developers try the CI out and gather feedback. -
Re-enable GitLab CI for the tails/tails project - i.e. revert tails/gitlab-config@58d7d87fe0ff7154d8f9e236734cb85b23eebd7e
-
Make GitLab CI runners reliable enough that we can us them on the tails/tails project -
Pulling from GitLab often results in 502 error: GitLab CI jobs fail to fetch Git: "RPC failed" (#17834 - closed) -
Use a local container registry mirror to avoid hitting hub.docker.io
limits
-
-
Set up GitLab CI runners on iguana so we can trust them somewhat -
Merge: "Add a GitLab Runner class" -- puppet-tails!92 (merged)
-
-
Clean up -
Remove Cucumber test scenarios that are now cov... (tails#17992 - closed) -
Remove Jenkins jobs that are now covered by Git... (#17776 - closed) -
remove the call to bin/sanity-check-website
inbuild-website
(tails!923 (merged))
-
-
Ensure that all the remaining ideas listed here are tracked elsewhere -
Evaluate how this setup works and what the next steps should be -
Close this issue
And then we can start using GitLab CI for more greatness (see related issues)
Potential candidates
Infrastructure
-
Improve performance of GitLab CI tests: install... (tails#18169) -
Estimate our needs for a container registry (#17840) -
If needed, build our own Docker images and use our own registry.
Public stuff, no credentials required
-
Run tests for tails-weblate-update.hook (#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 Run the doctests of our Python scripts (tails#15330) that can be done without booting Tails -
Prevent technical writers fom moving core pages... (tails#17877 - closed) -
GitLab CI: build website (tails#19149) - Linters:
- Run the Upgrader's test suite in CI (tails#17940)
- Regularly import updated PO files from Hosted W... (tails#18002)
- Prevent translations that fail the automated te... (#17809)
Sensitive stuff
- The build of our production website should be s... (#17364)
- Regularly merge master branch into stable and s... (tails#18003)
- Automatically run gitlabracadabra after pushing... (#17973)
- Allow ticket gardener to run gitlab-triage via ... (#17974)
- Weblate integration scripts (could improve reporting, collaboration and overall design) - Add GitLab CI tests for Weblate scripts (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 a local proxy/cache 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).