Unterstützung von Gitlab Runners

Die Wiener haben unter https://sharing-codeability.uibk.ac.at/sharing/vienna-university-of-technology/latex/-/pipelines ein Projekt eingecheckt, dass wohl einen Runner triggered.

Wir sollten uns eine Meinung dazu bilden, wie wir damit umgehen wollen:

• Unterstützen wir nicht
• Wir stellen einen Basis-Infrastruktur für Runner zur Verfügung?
• Projekte müssen Ihre eigenen Runners bereitstellen?

@lukas.kaltenbrunner Du scheinst dazu am besten Bescheid zu wissen. Kannst Du uns unterstützen uns dazu eine Meinung bilden?

changed milestone to %2021 Januar Sprint Sharing Plattform

Followingly, some basics of GitLab runners are discussed. Afterward, an example of a runner set up for the project sharing/vienna-university-of-technology/latex is given. Finally, I present my opinion, whether we should provide a runner.

GitLab Runner

In the following, I provide a brief extract of the GitLab Runner documentation.

Runners are the agents that run the CI/CD jobs that come from GitLab. There are three types of runners, based on who you want to have access:

• Shared runners are for use by all projects
• Group runners are for all projects and subgroups in a group. Every user with Owner permissions for the group can create those runners.
• Specific runners are for individual projects. Every user with Owner permissions for the project can create those runners.

GitLab runners can be installed on various operating systems like Linux, Windows, macOS. Furthermore, a GitLab Runner image is provided.

GitLab recommends that the runner be installed on a server separate from the GitLab installation.

Setup

Currently, the sharing-platform does not provide any shared runner. Consequently, a user willing to use the CI-CD capabilities of GitLab has to install a runner. To test the workflow and required labor, I am installing a specific runner for a fork of the project sharing/vienna-university-of-technology/latex in the development environment using a user without admin-permissions.

In the following, the required steps are briefly described.

1. I installed the docker image using local system mounts on my local computer using the following command.

docker run -d --name gitlab-runner --restart always \
    -v /srv/gitlab-runner/config:/etc/gitlab-runner \
    -v /var/run/docker.sock:/var/run/docker.sock \
    gitlab/gitlab-runner:latest

2. Go to the project’s Settings > CI/CD and expand the Runners section. Copy URL and Token.
3. Register a runner using the command docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register and follow the interactive setup of the runner:
   • Enter the GitLab instance URL (for example, https://gitlab.com/): https://sharing.codeability-austria.uibk.ac.at/ (copy from step 2)
   • Enter the registration token: xxx (copy from step 2)
   • Enter a description for the runner: latex_tu_wien
   • Enter tags for the runner (comma-separated): latex
   • Enter an executor: shell, ssh, docker+machine, kubernetes, docker-ssh, parallels, virtualbox, docker-ssh+machine, custom, docker: docker (seems appropriate for this project)
   • Enter the default Docker image (for example, ruby:2.6): timnn/texlive
4. Use CI-CD :)

My Opinion

The specific runner setup for the project sharing/vienna-university-of-technology/latex is fairly simple.

If we want to host our own code (e.g., Artemis, Git Search, Filehooks), we should definitively add a shared/group runner for convenience. Docker-in-docker (e.g., docker:20.10-dind) seems to be a good choice for a general-purpose executor. For example, the project sharing/vienna-university-of-technology/latex also works with this executor.

In my opinion, we should add a group runner for the sharing group. However, a sever for this runner would be needed.

Danke für die Info.

Momentan prüfen wir gerade den Kubernetes Update für ArTEMiS.

Anschliessend sollten wir uns die Sharing Plattform und ggf. die Runners vornehmen.

closed