This task is something of a loosely-sketched placeholder, but I figured I should get this conversation started.
We plan to migrate CI to GitLab, which in practice means using .gitlab-ci.yml.
Comparison
There's a lot of overlap between .gitlab-ci.yml concepts and what PipelineLib and our .pipeline/config.yaml provide. Below is a simple requirements/feature matrix based off of current PipelineLib features that should be filled in to compare against GitLab's CI features and used to further evaluate the cost/benefit of migrating vs. porting.
A red flag question mark (❓) denotes an item needing more research. A red flag (🚩) denotes an item where the answer is mostly known, concerning, and would require a workaround.
| Category | Feature | GitLab CI (How it could be done) | PipelineLib (How it's done now) |
|---|---|---|---|
| Running jobs | environment images | arbitrary image ref [1] | local Blubber config/variant |
| arguments | simple config | simple config | |
| environment variables | simple config | simple config | |
| custom execution | defined stages or DAG | defined DAG | |
| credentials | masked group/project level variables | whitelisted by admin and bound in config | |
| save/pass artifacts | simple config and central store | simple config and local build context (temporary) | |
| process output | using artifacts | .output run-stage variables | |
| Building images | image definitions | Blubber config | Blubber config |
| image builders | simple config (via include that uses BuildKit + Blubber; see T308271) | blubberoid + docker | |
| operator constraints | Blubber conventions | Blubber conventions/policy | |
| Publishing images | naming/tagging | simple config (via include) | simple config |
| push to registry | simple config (via include that uses existing GitLab JSON Web Token; see T308501) | hidden credentials (docker-pusher) | |
| registry/repo enforcement | enforced by jwt-authorizer | enforced by admin | |
| Testing deployment | staging deployment | user script (helm) but k8s credentials exposed 🚩 | simple config |
| testing deployment | user script (helm test or other) but k8s credentials exposed 🚩 | simple config | |
| Promoting version | bumping chart value | user script (git commit/review) but needs downstream git creds 🚩 | simple config |
- Are users restricted to external image refs or can they specify a locally built image (without first publishing it)? It's not clear whether a restriction would be of concern.
- Using docker-in-docker is a security concern as it would require privileged containers.
Evaluation
Given the comparison. Can we answer the following?
- Is .pipeline/config.yaml or something like it still a desirable abstraction for Wikimedia projects? updated: Not enought to port and maintain. We will likely rely directly on .gitlab-ci-yml and provide includes for backwards compatibility.
- If so, what parts would need ported over from the current Groovy implementation and where would they fit? updated: No porting. We'll provide GitLab CI includes*
- If not, what do we need to do to migrate existing projects / users to a pure GitLab CI approach? updated: See above
I think @dduvall probably best knows the current PipelineLib implementation and design goals; hoping for input from @dancy and @jeena as well.