Start using GitLab CI for non-ISO jobs
As per our roadmap session made during Summit 2020.
- Next steps
- Potential candidates
- Current conclusions
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
Set up GitLab CI runners on iguana so we can trust them somewhat
Merge: "Add a GitLab Runner class" -- puppet-tails!92
Remove Cucumber test scenarios that are now cov... (tails#17992)
Remove Jenkins jobs that are now covered by Git... (#17776)
remove the call to
Evaluate our needs for a container registry -- Estimate our needs for a container registry (#17840)
If needed, build our own Docker images and use our own registry.
And then we can start using GitLab CI for more greatness (see related issues)
Public stuff, no credentials required
Run tests for tails-weblate-update.hook (#16712 - closed)
check_PO_master(Jenkins job definition,
check_PObuilder), that runs
lint_po, which itself uses
- It would be nice if translators could see the status of the CI check.
- This would allow us to run whichever version of
i18nspectorwe 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 as
check_PO_master, it would be nice to be able to choose the version of
Check PO files with
msgfmt. We'll see if it catches errors that
i18nspectormisses: if not, we should consider dropping the
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
- GitLab CI: build website (#17775)
- Run our custom programs test suite on interesti... (tails#17940)
- The build of our production website should be s... (#17364)
tails/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) - Add GitLab CI tests for Weblate scripts (puppet-tails!31 - merged)
- 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).
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information