Evaluate the opporunities of a migration from Jenkins to GitLab CI
- Identify the interest/opportunities to switch to GitLab CI
- Estimate the workload
- Design a migration plan
Activity
added activity::Design label
Over the past couple of months, I've been semi-passively looking at CI systems and their integration with GitLab. I've also been ramping up my knowledge of GitLab CI on personal/Debian projects.
As has been exemplified by our work on the Jenkins module for GitLab integration, most of the GitLab features for in-depth integration with CI systems (e.g. reporting of complex pipelines, display of detailed code coverage and linting results, display of test results, etc.) are hidden behind the runner and artifact APIs, which are effectively:
- underdocumented
- which makes them semi-private
- and eventually makes them tightly coupled to GitLab CI
The most practical and pragmatic solution to the CI integration problem, in my evaluation, is therefore to go with GitLab CI.
Most of the complexity of our existing CI pipelines for development tools comes from taking into account quirks of Jenkins, of Jenkins Job Builder, or of the GitLab/Jenkins integration.
The docker images currently used for CI can be directly reused into a GitLab CI workflow, and once that's done, the blanket migration of our pipelines will be fairly simple: every pipeline step is about running a handful of commands within one of these Docker images, which is trivial to do in GitLab CI. Most of our existing tools (mypy, flake8, pytest with coverage) have built-in or easily-found plugins to extract their results into formats that GitLab CI understands, and the Free Community Edition of GitLab seems to have most of the features that we have lost since the migration away from Phabricator (coverage reporting, test result reporting, etc.).
There seems to be buy-in (even eagerness) from other team members for this migration, as discussed during the team seminar. No obvious blockers have been identified.
The next step in this evaluation/migration is setting up the basic CI runner infrastructure, to enable writing concrete GitLab CI workloads.