As per our roadmap session made during Summit 2020. [[_TOC_]] # Next steps - [x] Let developers try the CI out and gather feedback. - [x] Re-enable GitLab CI for the tails/tails project - i.e. revert tails/gitlab-config@58d7d87fe0ff7154d8f9e236734cb85b23eebd7e - [x] Make GitLab CI runners reliable enough that we can us them on the tails/tails project - [x] Pulling from GitLab often results in 502 error: tails/sysadmin#17834+ - [x] Use a local container registry mirror to avoid hitting `hub.docker.io` limits - [x] Set up GitLab CI runners on iguana so we can trust them somewhat - [x] Merge: "Add a GitLab Runner class" -- puppet-tails!92 - [x] Clean up - [x] tails/tails#17992+ - [x] tails/sysadmin#17776+ - [x] remove the call to `bin/sanity-check-website` in `build-website` (tails!923) - [x] 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) :tada: # Potential candidates ## Infrastructure - [ ] tails#18169+ - [ ] sysadmin#17840+ - [ ] If needed, build our own Docker images and use our own registry. ## Public stuff, no credentials required - [x] tails/sysadmin#16712+ - [x] [`check_PO_master`](https://jenkins.tails.boum.org/job/check_PO_master/) ([Jenkins job definition](https://gitlab.tails.boum.org/tails/jenkins-jobs/-/blob/master/check_PO_master.yaml), [`check_PO` builder](https://gitlab.tails.boum.org/tails/jenkins-jobs/-/blob/master/macros/builders.yaml#L6)), that runs [`lint_po`](https://gitlab.tails.boum.org/tails/jenkins-tools/-/blob/master/slaves/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](https://github.com/jwilk/i18nspector/issues/6) we've requested after translation mistakes caused bugs in Tails. - [x] 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 - [x] Check PO files with `msgfmt`. We'll see if it catches errors that `i18nspector` misses: if not, we should consider dropping the `msgfmt` check. - [x] Check "meta date" directives in PO files - [x] WhisperBack's unit tests (added to our Cucumber test suite via tails/tails#16936, but arguably this would be better suited for GitLab CI) - [x] The subset of tails/tails#15330+ that can be done without booting Tails - [x] tails#17877+ - [ ] tails/tails#19149+ - Linters: - [x] ShellCheck (tails/tails!190+) - [ ] tails/tails#19307+ - [ ] tails/tails#19306+ - tails/tails#17940+ - tails#18002+ - tails/sysadmin#17809+ ## Sensitive stuff - tails/sysadmin#17364+ - tails#18003+ - tails/sysadmin#17973+ - tails/sysadmin#17974+ - Weblate integration scripts (could improve reporting, collaboration and overall design) - puppet-tails!31+ # 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).