GitLab

As per our roadmap session made during Summit 2020.

• Next steps
• Potential candidates
  • Public stuff, no credentials required
  • Sensitive stuff
• Current conclusions

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
• Set up production-ready GitLab CI runners
  • On iguana so we can trust them somewhat
  • Make them reliable enough that we can us them on the tails/tails project
    • Pulling from GitLab often results in 502 error
    • Use a local container registry mirror to avoid hitting hub.docker.io limits
• Clean up
  • tails#17992
  • #17776
  • remove the call to bin/sanity-check-website in build-website
• Evaluate 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) 🎉

Potential candidates

Public stuff, no credentials required

• #16712 (closed)
• check_PO_master (Jenkins job definition, check_PO builder), that runs lint_po, which itself uses i18nspector:
  • 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 as check_PO_master, it would be nice to be able to choose the version of i18nspector we're using
• Check PO files with msgfmt. We'll see if it catches errors that i18nspector misses: if not, we should consider dropping the msgfmt 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 (merged))

Sensitive stuff

• #17364
• Run gitlabracadabra from 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) - 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).