Start using GitLab CI for non-ISO jobs

As per our roadmap session made during Summit 2020.

• Next steps
• Potential candidates
  • Infrastructure
  • 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
• 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 in build-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 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 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 for QA (tails#19149)
• Linters:
  • ShellCheck (Establish a coding standards baseline on our sh... (tails!190 - merged))
  • Run Rubocop in GitLab CI (tails#19307 - closed)
  • Establish a coding standards baseline for our P... (tails#19306 - closed)
• Run the Upgrader's test suite in CI (tails#17940)
• Automatically & continuously import updated tra... (tails#18002)
• Prevent translations that fail the automated te... (#17809)

Sensitive stuff

• Build our production website in GitLab CI (#17364 - closed)
• Regularly merge master branch into stable and s... (tails#18003 - closed)
• Automatically run gitlabracadabra after pushing... (#17973)
• Allow ticket gardener to run gitlab-triage via ... (#17974 - closed)
• 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).