Start using GitLab CI for non-ISO jobs

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
• 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
• Clean up
  • Remove Cucumber test scenarios that are now cov... (tails#17992)
  • Remove Jenkins jobs that are now covered by Git... (#17776)
  • remove the call to bin/sanity-check-website in build-website
• 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) 🎉

Potential candidates

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
• GitLab CI: build website (#17775)
• Run our custom programs test suite on interesti... (tails#17940)
• Linters:
  • Rubocop (Establish a coding standards baseline on our Ru... (tails#17646 - closed))
  • ShellCheck (Establish a coding standards baseline on our sh... (tails!190 - merged))

Sensitive stuff

• The build of our production website should be s... (#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) - 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 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).