This page briefly explains the Gitlab based infrastructure of the OpenEBS CI framework.
Gitlab CI Server
The Cloud-Native Gitlab (EE) Server (represented by the black box in the schematic diagram) is hosted on a multi-node baremetal OpenShift Cluster with all its components (Unicorn, Shell, Workhorse, Registry, Sidekiq, Gitaly, PostgreSQL, Redis, Minio) running as deployments.
The Gitlab CI server is integrated & setup to monitor the OpenEBS Github source repositories
(maya, jiva, zfs/cStor & e2e) via pull-based repository mirroring, i.e., creation of Gitlab
repositories corresponding to its respective source on Github, that are automatically updated
via a webhook mechanism whenever there are commits to the source repos. These repositories
are configured with the
.gitlab-ci.yml files that specify the build/CI steps to be performed
As part of Gitlab’s CI orchestration, each of the aforementioned OpenEBS components is configured with dedicated Gitlab Runners, which are responsible for running the Gitlab Jobs carrying out the build steps. The Gitlab runner implements different kinds of “executors”, i.e., entity (machine) that runs these steps. The Maya & Jiva repositories are mapped to “Shell Executors” that run the build steps in pre-configured VMs (installed with all build dependencies), while the zfs/cStor & e2e repositories are mapped to “Docker-Machine” executors which are lightweight VMs with Docker installed. In case of the latter, the build steps are carried out inside the docker containers running on the executor (the docker image contains the necessary build tools and packages). The “docker-machine” executors are inherently auto-scaling, which is a necessary feature for e2e builds, as multiple parallel jobs are spawned during the course of e2e pipeline stages.