GitLab

Git ist eine Software zur Versionsverwaltung von Dateien. Es ist primär dazu gedacht, Textdateien wie Quellcode, Latex-Dateien oder Skripte zu verwalten. Mit GitLab (https://gitlab.gwdg.de) stellt die GWDG einen Dienst zur Verfügung, mit dem sogenannte Git Repositories einfach verwaltet werden können. Neben der Versionsverwaltung bietet GitLab zusätzlich Management-, Bug-Tracking- sowie Wiki-Funktionalitäten an. Weiterhin lassen sich bei der Zusammenarbeit mit mehreren Personen Überprüfungen von Änderungen über sogenannte „Merge Requests“ durchführen. GitLab ist dem bekannten kommerziellen Dienst github sehr ähnlich.

Weitere Informationen zu git und mögliche Anwendungsfälle finden Sie hier.

Automatisch nutzungsberechtigt sind alle Mitarbeiter und Studierende der Universität Göttingen sowie Mitarbeiter der Max Planck Gesellschaft.

Studierende und Mitarbeiter der Universität Göttingen sowie Kunden mit einem GWDG-Account melden sich einfach wie gewohnt mit ihrer E-Mailadresse und ihrem Passwort an. Mitarbeiter der Max Planck Gesellschaft, die keinen GWDG-Account besitzen, können sich auf https://gwdg.de mit Ihrer Instituts eMail-Adresse registrieren.

In begründeten Einzelfällen ist es zudem möglich, auch externen Benutzern Zugriff auf GitLab zu geben. Wenden Sie sich diesbezüglich bitte an support@gwdg.de.

Benutzer können bis zu 50 GitLab-Projekte anlegen. Sollten Sie mehr Projekte benötigen, wenden Sie sich bitte an support@gwdg.de.

Git-Repositories sind nicht dafür ausgelegt, große binäre Formate (Bilder, Office Dateien, Multimedia-Dateien) zu speichern. Bitte nutzen Sie für diese Zwecke GWDG ownCloud.

Der Speicherplatz einzelner Projekte ist aktuell nicht limitiert. Sollte uns eine unsachgemäße oder missbräuliche Nutzung von GWDG GitLab auffallen, werden wir Sie kontaktieren und eine passende Lösung erarbeiten. Wir behalten uns vor, den Schreibzugriff auf auffällige Projekte temporär zu sperren.

Den Überblick über die Abhängigkeiten vieler Projekte zu behalten, ist mühsam. Unser zentraler Renovate-Dienst prüft Ihr Projekt alle zwei Stunden und öffnet einen Merge Request, sobald für eine Abhängigkeit eine neuere Version verfügbar ist – diesen prüfen Sie dann wie jeden anderen MR. Jedes Projekt wird in einem eigenen, kurzlebigen Container verarbeitet, sodass Projekte gegenseitig keinen Einblick in ihren Code haben.

Um den Dienst zu nutzen, laden Sie den Benutzer @renovate-bot mit der Rolle Developer in Ihr Projekt ein. Beim nächsten Durchlauf erhalten Sie einen Merge Request “Configure Renovate”, der eine renovate.json hinzufügt. Sobald Sie ihn mergen, öffnet Renovate Update-MRs, und ein Issue “Dependency Dashboard” gibt Ihnen einen Überblick (sofern Issues in Ihrem Projekt aktiviert sind).

Laden Sie den Bot bitte nur als Developer ein, niemals als Maintainer. Developer genügt, um MRs zu öffnen – als Maintainer könnte der Bot in geschützte Branches mergen und Ihre CI/CD-Secrets lesen. Schützen Sie außerdem Ihren Default-Branch (nur Maintainer), damit jede Änderung des Bots über Ihr Review läuft.

Öffentliche Registries funktionieren ohne Weiteres. Bei Registries mit Anmeldung kann der Bot die CI/CD-Variablen Ihres Projekts nicht verwenden. Führen Sie Renovate in diesem Fall als eigenen Job in der Pipeline Ihres Projekts aus – und laden Sie den Bot dann nicht zusätzlich ein, damit keine doppelten MRs entstehen.

Um Renovate zu beenden, entfernen Sie einfach den Bot aus Ihrem Projekt.

Seit der Umstellung auf SSO-only können private Projekte per http(s) nicht mehr mit dem Account-Passwort erreicht werden. Es gibt dazu drei mögliche Lösungen:

1. (empfohlen!) Nutzung von SSH. Wie man es einrichtet, können Sie hier nachlesen. Bei der ersten Anmeldung mit Ihrem neuen SSH-Schlüssel werden Sie aufgefordert, die Integrität des Servers zu überprüfen. Den Fingerabdruck finden Sie hier. Beachten Sie, dass Sie den Remote-Origin Ihrer lokalen Repositories ändern müssen, um die SSH-URL zu verwenden, entweder mit dem Befehl

git remote set-url origin git@gitlab.gwdg.de:Path/to/project.git oder durch direktes Bearbeiten des url-Feldes in
.git/config.

1. Verwenden Sie ein Token. In Ihren Kontoeinstellungen können Sie ein “persönliches Zugriffstoken” mit den von Ihnen benötigten Berechtigungen generieren. Diese Token haben eine maximale Lebensdauer von einem Jahr und Sie können sie wie ein Passwort verwenden, sobald Sie dazu aufgefordert werden. Es gibt auch Token, die in einer Gruppe oder in einem Projekt erstellt werden und normalerweise in speziellen Kontexten verwendet werden.
2. Ein Passwort setzen. Sie können auch ein Passwort innerhalb von GitLab festlegen. Wir empfehlen diese Methode nicht.

Bis Gitlab 15 konnten Access Token ohne explizites Verfallsdatum erstellt werden. Ab Version 16 ist das nicht mehr möglich. Alle Zugriffstoken ohne Ablaufdatum erhalten ein Ablaufdatum von einem Jahr. Bei persönlichen Access Token müssen Sie sich keine Sorgen machen, da Gitlab Sie automatisch sieben Tage vor dem Ablaufdatum per E-Mail informiert.

Neben persönlichen Access Token bietet Gitlab auch die Möglichkeit, Access Token auf Gruppen- oder Projektebene zu erstellen. In diesem Fall wird keine Benachrichtigungs-E-Mail an Sie gesendet. In diesem Fall sollten Sie Ihre Gruppen/Projekte auf Access Token überprüfen und deren Ablaufdatum selbstständig kontrollieren.

Für bestimmte Anwendungsfälle sind Access Token nicht erforderlich. Access Token geben Ihnen die Möglichkeit, Zugriff auf Repositories (lesen/schreiben), Paket- und Container-Registry (lesen/schreiben) oder auch Zugriff auf die API (lesen/schreiben) zu erhalten. Wenn Sie das Token nur zum Klonen des Repositories oder für den Zugriff auf die Paket- oder Container-Registry verwenden, wäre ein einfacher Workaround die Verwendung von Deploy-Tokens (erstellt unter Einstellungen > Repository > Deploy-Tokens).

Wenn Sie Token in CI-Pipelines verwenden, kann CI_JOB_TOKEN ebenfalls eine gute Alternative sein. Für CI_JOB_TOKEN können Sie auch den Geltungsbereich festlegen, d.h. sie können so konfiguriert werden, dass sie den Zugriff auf andere Projekte auf der Gitlab-Instanz erlauben.

Aufträge von CI/CD Pipelines werden von so genannten “CI Runnern” ausgeführt. Die GWDG betreibt eine Reihe von “Shared Runnern”, die standardmäßig allen Projekten zur Verfügung stehen. Da diese Runner Aufträge von unterschiedlichen Projekten und Benutzern ausführen, haben sie besonders hohe Sicherheitsanforderungen. Einige Funktionen wurden daher deaktiviert, unter anderem der Zugriff auf den Docker-Daemon.

Wenn Sie Gitlab CI/CD Pipelines zum Bauen von Docker-Images nutzen wollen, haben sie zwei Möglichkeiten:

1. Verwenden sie Werkzeuge, die Docker-Images auch ohne Zugriff auf den Docker-Daemon erstellen können. Die GWDG bietet hierfür ein Kaniko-Image an, das regelmäßig aus dem Chainguard-Fork gebaut wird. Hierfür einfach harbor.gwdg.de/gwdg/kaniko:debug als Image wählen.
2. Sie betreiben einen eigenen Runner und folgen der Anleitung.

Die “Pipelines” Funktion kann in den Projekt-Einstellungen unter “Settings → General → Visibility, project features, permissions → Pipelines” aktiviert werden. Zusätzlich ist eine “.gitlab-ci.yaml” Definitionsdatei im Projekt-Verzeichniss nötig. Näheres entnehmen sie bitte der offiziellen Gitlab CI/CD Dokumentation.

Die GWDG betreibt so genannte “Shared Runner”, die CI/CD Jobs ausführen können. Diese sind für alle Projekte automatisch aktiviert und nutzbar. Sollten sie besondere Anforderungen haben, wie zum Beispiel docker-in-docker oder Zugriff auf geschützte Ressourcen, empfiehlt es sich, einen eigenen Runner zu betreiben. Die entsprechenden Optionen und eine Kurzanleitung finden sie unter “Settings → CI/CD → Runners”.

Unter Windows kann der unerwartete Fehler auftreten, dass zwar eine Verbindung per SSH möglich ist, z.B. über den Test ssh -T git@gitlab.gwdg.de, Git-Befehle hingegen scheitern. Das Problem liegt ggfs. an einem P-Laufwerk, sodass Git unerwartet in einem falschen Verzeichnis in den .ssh Konfigurationsordner schaut und dadurch die falschen SSH-Keys probiert, sodass letztlich ein Authentifizierungsfehler auftritt. Die Lösung ist, Git entsprechend zu konfigurieren, sodass der “richtige”, d.h. lokale, Konfig-Ordner genommen wird. Das kann wie folgt umgesetzt werden:

git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe -F C:/Users/%USERNAME%/.ssh/config"