Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • S sysadmin
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 85
    • Issues 85
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • tails
  • sysadmin
  • Issues
  • #17740
Closed
Open
Issue created Aug 20, 2020 by Zen Fu@zenMaintainer

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 (tails#19149)
  • Linters:
    • ShellCheck (Establish a coding standards baseline on our sh... (tails!190 - merged))
    • Run Rubocop in GitLab CI (tails#19307)
    • Establish a coding standards baseline for our P... (tails#19306)
  • 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).
Edited Nov 30, 2022 by intrigeri
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking