Gitlab Continuous Integration

Passend zu Gitlab bietet der FB3 den zugehörigen CI-Dienst Gitlab-CI unter folgender URL an:

• https://ci.gitlab.informatik.uni-bremen.de/

Die Anmeldung erfolgt via oAuth über Gitlab, d.h. man meldet sich zuerst bei Gitlab an und klickt dann im Gitlab-CI-Interface einfach den "Login with Gitlab"-Button. Bei der ersten Anmeldung muss Gitlab-CI autorisiert werden, den Gitlab-Account nutzen zu dürfen.

In Gitlab bestehende Projekte können per Knopfdruck in Gitlab-CI eingebunden werden.

Siehe auch die offizielle Dokumentation.

Runner

Der Gitlab-CI-Server, auch Koordinator genannt, führt selbst keine Builds aus, sonder delegiert dies an sogenannte Runner. Ein Runner ist ein Prozess, der auf einem beliebigen Rechner laufen kann, und den Koordinator pollt, um anstehende Jobs abzuholen und zu bearbeiten. Dabei ist zwischen "Shared"- und "Specific"-Runnern zu unterscheiden. Ein Specific-Runner bedient nur bestimmte Projekte, während Shared-Runner alle Jobs abarbeiten, für die kein Specific-Runner existiert und die für die Nutzung von Shared-Runnern freigeschaltet sind (siehe die Option "Allow shared runners" in den Gitlab-CI-Projekteinstellungen).

Da nicht immer alle Jobs in allen Umgebungen funktionieren, kann mit Tags gesteuert werden, welche Jobs auf welchen Runnern ausgeführt werden können. Wenn einem Job Tags zugeordnet wurden, wird dieser nur auf einem Runner mit den passenden Tags ausgeführt. Wenn mehrere Runner für die Ausführung eines Jobs in Frage kommen, wird einer davon per Zufall ausgewählt.

Shared-Runner

Der FB3 stellt eine Reihe von Shared-Runnern zur Verfügung:

Die Linux- und MacOS-Runner laufen auf den Pool-Rechnern in der E0 im MZH, wodurch man vor dem Anlegen von Jobs problemlos manuell testen kann, ob die Umgebung den Anforderungen genügt. Zum SunOS-Runner gibt es derzeit keinen öffentlichen Zugang.

Fehlende Pakete, die für die Ausführung eines Jobs benötigt werden, können auf Anfrage nachinstalliert werden. Dazu kann man einfach eine E-Mail an <service AT informatik DOT uni-bremen DOT de> senden.

Shared-Runner kann man sich über das Gitlab-CI-Interface nicht auflisten lassen und werden auch nicht im Runners-Tab in der Projektansicht angezeigt. Man kann nur im Nachhinein über das Build-Log feststellen, auf welchem Shared-Runner ein Job ausgeführt wurde.

Specific-Runner

Man kann auch eigene Specific-Runner erstellen, die dann nur die eigenen Projekte bedienen. Der Vorteil ist, dass man die Entwicklungsumgebung individuell anpassen, oder auch einfach eine bestehende Umgebung direkt weiter benutzen kann. Voraussetzung für den Betrieb eines Runners ist, dass dieser den Gitlab-CI-Server im Netzwerk erreichen kann.

Weitere Informationen zum Erstellen eigener Runner sind im Runners-Tab in der Projektansicht in Gitlab-CI zu finden.

Sicherheit

Bei der Benutzung und Einrichtung von Runnern sollten einige Punkte in Hinsicht auf Sicherheit und den Schutz vertraulicher Daten beachtet werden:

Jobs sind beliebige Shell-Skripte, die mit den Rechten des Benutzers ausgeführt werden, unter dem der jeweilige Runner-Prozess läuft. Das bedeutet, dass jeder Gitlab-Benutzer, der die entsprechenden Zugriffsrechte auf ein Projekt hat, beliebige Befehle mit den Rechten der Runner ausführen kann, die das jeweilige Projekt bedienen.

Gerade beim Einrichten eigener Runner sollte also darauf geachtet werden, dass keine vertraulichen Informationen zugreifbar sind und dass der Runner nicht mehr Rechte auf dem unterliegenden System hat, als er für die Bearbeitung seiner Jobs benötigt.

Insbesondere bei Shared-Runnern ist zu beachten, dass dadurch z.B. der private Authentisierungs-Token des Runners ausgelesen werden und dadurch der Runner von einer anderen Maschine imitiert werden könnte. Außerdem ist es möglich, direkt auf den Code der bisher vom jeweiligen Runner bearbeiteten Projekte zuzugreifen, solange diese im Arbeitsverzeichnis des Runners verbleiben.

Jobs

Jobs sind beliebige Shell-Skripte (in der Regel bash), die im Wurzelverzeichnis des Projektes ausgeführt werden. Dabei wird zwischen Test- und Deploy-Jobs unterschieden. Test-Jobs werden parallel zueinander, und ggf. auch auf unterschiedlichen Runnern, ausgeführt. Ein Deploy-Job wird nur dann ausgeführt, wenn alle Test-Jobs erfolgreich beendet wurden.