TRAINING TESTING GITLAB
Für dieses Tutorial solltest du dich bereits mit dem Versionsverwaltungssystem Git auskennen. Einer der bekanntesten Betreiber, der eine Versionsverwaltung auch über das Internet anbietet, ist GitHub. Dadurch wird die Arbeit an einem Projekt in Teams oder über verschiedene Geräte hinweg deutlich vereinfacht. Ein anderer Anbieter ist GitLab. Letzterer bietet nicht nur die Codeverwaltung auf seinen Servern an, sondern bietet seine Software auch zum Betrieb auf eigenen Servern an. Die WWU Münster stellt ein solches System auf ihren Servern bereit:
Beachte, dass du für dieses Kapitel *Git* installiert haben musst. Falls dies noch nicht der Fall ist, kannst du hier die aktuelle Version herunterladen. Du findest dort auch Anleitungen für verschiedene Betriebssysteme.
Einführung
Üblicherweise umfasst das Git-Repository zu einem Projekt die vollständige Entwicklung. Deshalb ist es sinnvoll das Repository anzulegen bevor mit der Implementierung begonnen wird. Für den Fall, dass erst nachträglich entschieden wird, ein Projekt mit GitLab zu verwalten, werden in diesem Kapitel jedoch zwei Varianten vorgestellt.
Voraussetzung ist zunächst, dass wir einen Account im WWU-GitLab oder auf GitLab.com angelegt haben. In diesen loggen wir uns dann auf https://zivgitlab.uni-muenster.de/ bzw. GitLab.com ein:
Unser Ziel ist es, später Befehle wie git push oder git pull aufrufen zu können, um unseren lokalen Stand mit dem Stand des Remote Repositories zu synchronisieren. Um die dafür benötigte Verbindung aufzubauen, empfiehlt es sich im GitLab einen sogenannten SSH-Key zu hinterlegen.
SSH-Key hinterlegen
Falls du das GitLab noch nie verwendet hast, ist es zunächst notwendig diesem mitzuteilen, dass dein Gerät vertrauenswürdig ist. Diese Schritte musst du nur einmal für alle Projekte auf deinem Computer wiederholen, dafür jedoch für jeden Computer getrennt. Ohne eine weitere Passworteingabe kann der GitLab-Server dadurch sicherstellen, dass nur Personen bzw. Geräte etwas an dem Repository ändern, die dazu berechtigt sind.
A. Existierenden SSH-Key nutzen
Eventuell besitzt du bereits einen SSH-Key. Diesen kannst du dann einfach verwenden. Er liegt üblicherweise in deinem Home-Verzeichnis in einem Ordner .ssh/. Falls dieser Ordner leer ist oder nicht existiert, hast du vermutlich noch keinen SSH-Key und musst einen neuen generieren (siehe nächster Abschnitt).
Die SSH-Keys bestehen immer aus einem Pärchen bestehend aus einem privaten und öffentlichen Schlüssel. Es gibt verschiedene Algorithmen mit denen die Schlüssel generiert werden können. Üblicherweise sind die Dateien entsprechend benannt:
| Algorithmus | Public Key | Private Key |
|---|---|---|
| ED25519 (bevorzugt) | id_ed25519.pub | id_ed25519 |
| RSA (mindestens 2048-Bit großer Key) | id_rsa.pub | id_rsa |
| DSA (veraltet) | id_dsa.pub | id_dsa |
| ECDSA | id_ecdsa.pub | id_ecdsa |
B. Neuen SSH-Key generieren
Wenn du noch keinen SSH-Key besitzt, musst du ein neues Schlüssel-Paar generieren. Du kannst dazu das Programm ssh-keygen nutzen. Wahrscheinlich hattest du dieses (abhängig von deinem Betriebssystem) bereits installiert oder hast es zusammen mit Git installiert. Führe in einer Konsole den folgenden Befehl aus:
ssh-keygen -t ed25519 -C "<comment>"
Du wirst nun gefragt, wo du das neue Schlüssel-Paar speichern möchtest. Falls du unsicher bist oder keinen besonderen Grund hast, solltest du es bei der Standardeinstellung belassen und diese mit Enter bestätigen.
Als nächstes wirst du nach einem Passwort gefragt. Mit diesem kannst du den Zugriff auf den Schlüssel beschränken. Es ist möglich kein Passwort zu vergeben, aber beachte, dass dann jeder mit Zugang zu deinem Gerät auch auf den Schlüssel zugreifen kann. Mit dem privaten Schlüssel kann man sich gegenüber dem GitLab-Server (und anderen Servern auf denen du deinen öffentlichen Schlüssel hinterlegst) als du ausgeben. Das hier eingegebene Passwort stellt eine zusätzliche Sicherheitshürde dar und muss bei jedem Zugriff auf den Server (bzw. dafür benötigten privaten Schlüssel) eingegeben werden.
SSH-Key hinterlegen
Du solltest nun in jedem Fall einen SSH-Key besitzen. Dieser ist in einer Datei im Ordner ~/.ssh gespeichert. Du brauchst lediglich den öffentlichen Schlüssel und solltest auch sonst den privaten Schlüssel niemals weitergeben! Kopiere den Inhalt der Datei mit der Endung .pub. Dies ist dein öffentlicher Schlüssel, den du im GitLab hinterlegen musst.
Navigiere dazu im GitLab zu deinen Einstellungen:
Wähle dort den Reiter "SSH Keys" aus und füge deinen kopierten Key in das dafür vorgesehene Feld ein. Er sollte ähnlich zu dem unten gezeigten Key aussehen. Zusätzlich kannst du einen Titel vergeben, sodass du später weißt, welchen Geräten du eine Berechtigung erteilt hast.
Du kannst deinen Key nun hinzufügen und die Einstellungen anschließend verlassen.
A. Projektstart (noch kein Code vorhanden)
Haben wir noch nicht mit der Implementierung begonnen, können wir damit starten, im GitLab ein neues Projekt anzulegen. Direkt auf der Startseite können wir ein neues Projekt erzeugen:
In unserem Fall entscheiden wir uns für eine leeres Projekt ("Create blank project"), aber es können auch verschiedene Templates ausgewählt werden. Auf der nächsten Seite können wir einen Namen wählen und einige andere Einstellungen vornehmen.
Nun haben wir bereits unser eigenes Projekt erstellt und können dieses herunterladen indem wir es klonen. Dazu kopieren wir die SSH-URL, welche wir direkt auf der Startseite unseres Projekts unter "Clone" finden.
Auf unserem Computer (dessen SSH-Key wir zuvor im GitLab hinterlegt haben) öffnen wir anschließend eine neue Konsole und führen dort den folgenden Befehl mit unserer URL aus:
git clone git@zivgitlab.uni-muenster.de:reach-euregio/deployment-tutorial.git
Der neu angelegte Ordner ist unser lokales Repository, in welchem wir mit unserer Implementierung beginnen können. Dort stehen uns auch alle bekannten Git-Befehle zur Verfügung.
Sollten wir doch schon einige Dateien besitzen, die wir zu dem Repository ergänzen möchten, können wir diese natürlich auch einfach in diesen Ordner verschieben und mit git add [PATH] dem Repository hinzufügen. Alternativ erzeugen wir das Repository direkt in dem entsprechenden Ordner, wie es in dem folgenden Abschnitt erläutert wird.
B. Lokaler Code existiert bereits
Haben wir bereits mit der Implementierung begonnen, gehen wir einen anderen Weg, um unser Projekt doch noch mithilfe des GitLabs verwalten zu können. Zwar können wir auch einfach die bisherigen Dateien in ein neues geklontes GitLab-Projekt kopieren, wenn wir vorher schon Git ohne einen Remote Server zur Versionsverwaltung verwendet haben, verlieren wir auf diese Weise jedoch alle bis dahin erstellten Commits. Verwaltest du deinen Code schon in einem lokalen Repository, kannst du den folgenden Unterabschnitt überspringen.
Lokales Repository vorbereiten
Falls noch nicht geschehen, müssen wir nun ein neues Git-Repository anlegen. Navigiere dazu in einer Konsole in den Hauptordner deines Projekts und rufe dort git init auf. Git legt dann ein neues leeres Repository an.
Bei größeren Projekten solltest du diesen Schritt schon zu Beginn erledigen, um die Vorteile einer Versionsverwaltung während der Entwicklung nutzen zu können.
Die Benutzung von Git ist vorerst wie schon bekannt möglich. Zunächst müssen eine E-Mail-Adresse und der Name konfiguriert werden und anschließend können Commits erstellt werden.
git config user.email "you@example.com" git config user.name "Your Name" git add app/train.py app/test.py app/utils.py .gitignore git commit -m "TensorFlow train and test scripts"
Remote Repository verknüpfen
Auch wenn damit eine grundsätzliche Versionsverwaltung möglich ist, funktioniert der Befehl git push logischerweise noch nicht. Git macht uns stattdessen einen Vorschlag, den wir befolgen können, um ein dafür notwendiges Remote Repository hinzuzufügen. Es werden ein Name und eine URL benötigt. Standardmäßig nennt man das Remote Repository origin. Die URL ist etwas komplizierter. Da auf dem GitLab Server bisher kein entsprechendes Projekt existiert, legen wir dieses implizit über die Wahl der URL an. Der erste Teil git@ ist immer gleich. Danach folgt die Adresse des Servers. Im Fall des WWU-GitLabs ist das [zivgitlab.uni-muenster.de](http://zivgitlab.uni-muenster.de). Getrennt von einem : wird der Nutzername oder die Gruppe angegeben, wo das Projekt liegen soll. Wenn es keinen besonderen Grund für eine andere Entscheidung gibt, sollte hier immer der eigene Nutzername verwendet werden. Nach einem / folgt schließlich der Name des Projekts und .git. Der Name sollte keine Leerzeichen enthalten und du darfst noch kein Projekt mit dem gleichen Namen besitzen. Falls du dir unsicher bist, kannst du auch erstmal ein neues Projekt im GitLab anlegen und dort den Link unter "Clone" als Vorlage verwenden (siehe A. Projektstart (noch kein Code vorhanden)).
In unserem Fall lautet der gesamte Befehl damit:
git remote add origin git@zivgitlab.uni-muenster.de:reach-euregio/deployment-tutorial.git
Da auch der main-Branch für das Remote Repository neu ist, muss dieser beim ersten Push explizit angegeben werden:
git push --set-upstream origin main
In der GitLab-Oberfläche wurde nun automatisch ein neues Projekt angelegt und kann dort weiter verwaltet werden. In den Einstellungen des Projekts können nachträglich alle Änderungen vorgenommen werden, die sonst bei der Erzeugung des Projekts angepasst worden wären.