FAQ - Software Engineering Services (GitLab)

Aktuell können pro Gitlab-Account (SSO) 50 Projekte gleichzeitig angelegt werden.

Damit sich externe Nutzende an der zentralen GitLab Instanz anmelden können, um an bereits existierenden Projekten mitzuarbeiten, ist es möglich, sich mit einem Github Account anzumelden (dieser ist, sofern noch nicht vorhanden, auf https://github.com (wird in neuem Tab geöffnet) zu erstellen). Dazu auf der Startseite https://git.rwth-aachen.de (wird in neuem Tab geöffnet) bzw. https://git-ce.rwth-aachen.de (wird in neuem Tab geöffnet) einfach das Github-Logo anklicken. Dabei ist zu beachten, dass Nutzende, die sich über Github einloggen, in Gitlab als External gekennzeichnet werden und dadurch keine Projekte erstellen dürfen.

Dies hängt mit der Login Umstellung vom 03.05.2023 zusammen:

https://blog.rwth-aachen.de/itc/2023/04/26/gitlab/ (wird in neuem Tab geöffnet)

Nach dem Login wurde ein neuer Account generiert, da sich Ihre Kontakt-Mail-Adresse aus dem IdM Selfservice (wird in neuem Tab geöffnet) und die primäre E-Mail-Adresse ihres eigentlichen GitLab Accounts unterscheiden.

Der alte Account existiert allerdings weiterhin. Mit folgenden Schritten können Sie das Problem selbstständig lösen:

1. Setzen Sie die primäre E-Mail-Adresse Ihres ursprünglichen Accounts als Kontakt-Mail-Adresse im Selfservice (wird in neuem Tab geöffnet)
2. Löschen Sie den neuen Account selbstständig (git-ce: https://git-ce.rwth-aachen.de/-/profile/account (wird in neuem Tab geöffnet)   // git.rwth: https://git-ce.rwth-aachen.de/-/profile/account (wird in neuem Tab geöffnet))
3. Warten Sie eine Synchronisationszeit von etwa 20 Minuten ab
4. Jetzt können Sie sich wieder in den ursprünglichen Account einloggen

*Sollte die Mail für 1. nicht bekannt sein, melden Sie sich bitte beim IT-ServiceDesk

Hinweis: Anschließend können Sie Ihre E-Mail-Adressen wieder beliebig ändern, da eine neue ID in Ihrem GitLab Account gespeichert wurde.

Der Github-Login ist nur für externe Projektpartner vorgesehen, die sich nicht via SSO authentifizieren können. Daher diesen bitte nur nutzen, wenn kein SSO-Login zur Verfügung steht, da ansonsten der Account als extern geflaggt und die Berechtigung zum Erstellen von Projekten entzogen wird.

Anmeldung über DFN-AAI

Dies hängt mit der Umstellung des Logins vom 03.05.2023 zusammen:

https://blog.rwth-aachen.de/itc/2023/04/26/gitlab/ (wird in neuem Tab geöffnet)

Wenn der Fehler auftritt, bedeutet dies, dass Ihre Kontakt-Mail-Adresse aus dem Selfservice (wird in neuem Tab geöffnet), nicht als primäre Mail-Adresse in GitLab gesetzt ist, aber als z.B.: sekundäre Mail-Adresse.

Sie können die Problematik selbst lösen, indem Sie im Selfservice (wird in neuem Tab geöffnet) die Kontakt-Mail-Adresse auf die aktuell primäre Adresse Ihres GitLab Accounts ändern, einen Synchronisationszeitraum von 20 Minuten abwarten, und sich dann erneut einloggen.

Hinweis: Diese Maßnahme ist nur einmalig notwendig, um eine neue ID in GitLab zu hinterlegen. Sie können anschließend alle Mail-Adressen wieder beliebig ändern.

Anmeldung über GitHub

Der Fehler kann dadurch verursacht werden, dass Sie sich über GitHub angemeldet haben. Der Login über den RWTH Single Sign-On funktioniert nicht, wenn die Kontakt E-Mail-Adresse im Identity Management der RWTH (wird in neuem Tab geöffnet) identisch ist mit der E-Mail-Adresse aus GitHub.

Wenn Sie sich über GitHub einloggen können, versuchen Sie bitte den Login über den RWTH Single Sign-On selbständig zu aktivieren:

1. Loggen Sie sich, sofern möglich, über GitHub ein.
2. Klicken Sie auf Ihrem Dashboard oben rechts auf das Avatar-Symbol.
3. Klicken Sie in dem Menü, das sich aufklappt, auf "Edit Profile".
4. Klicken Sie links in der Navigation auf "Account".
5. Klicken Sie im Abschnitt "Social sign-in" auf den Button "DFN-AAI Single Sign-On", um sich mit dem RWTH Single Sign-On anzumelden.

Anschließend können Sie sich sowohl über GitHub als auch über den RWTH Single Sign-On anmelden.

Um Projekte und/oder Gruppen erstellen zu können, müssen Sie zusätzlich freigeschaltet werden. Teilen Sie uns hierzu bitte Ihren GitLab-Nutzernamen mit (diesen finden Sie, wenn Sie oben rechts auf das Avatar-Symbol klicken, hinter dem @).
Wir erteilen die entsprechenden Berechtigungen.

Aus Sicherheitsgründen können keine E-Mail-Adressen der Domänen @outlook.com oder @hotmail.com als Kontakt-E-Mail-Adressen im IdM Selfservice oder für GitHub-Accounts verwendet werden.

Um das Problem zu beheben, verwenden Sie eine E-Mail-Adresse aus zugelassenen Maildomänen. 

Bei der Änderung der Kontakt-E-Mail-Adresse im Selfservice benötigt das System ca. 20 Minuten, um Daten zu synchronisieren. Anschließend können Sie sich erneut einloggen.

Bei der Anmeldung mit dem Single Sign-On (SSO) kann es zur Fehlermeldung "Return Parameter ist nicht auf Positivliste enthalten" kommen.

Bitte leeren Sie in diesen Fällen Ihren Browser Cache, bevor Sie versuchen sich erneut anzumelden.

Sobald eine Gruppenberechtigung gesetzt ist, kann für Angehörige dieser Gruppe keine individuelle Benutzerberechtigung erteilt werden die von der Gruppenberechtigung abweicht.

Die Nutzenden können ihren Benutzernamen unter "Profile → Account" selbstständig ändern. Dabei ist zu beachten, dass sich mit Änderung des Benutzernamens auch der Namespace ändert. Dies hat zur Folge, dass sich ebenfalls auch die Links zu bereits bestehenden Projekten ändern.

Bei einem Git-Clone (über https) muss bei der Anmeldung der Benutzername aus GitLab (nicht die Email und nicht den Shibboleth Benutzernamen) und das Access-Token, welches vorher über die GitLab-Oberfläche generiert werden muss (User Settings - Access Tokens). Die Anmeldung über den Benutzernamen (Format: ab123456) und zugehörigem Kennwort funktioniert nicht.

Als Gruppe können beliebig viele Projekte erstellt werden. Die Anzahl an Projekten einer Gruppe hat keinen Einfluss auf die Quota der einzelnen Gruppenmitglieder.

Für push & pull kann sich in GitLab auch klassisch mit Benutzername und Kennwort authentifiziert werden. Dieses Kennwort muss jedoch im GitLab Benutzer-Profil gesetzt werden. Sobald eins gesetzt worden ist, gelingt auch der push & pull per https.

Aktuell bieten wir keinen GitLab Runner für alle Nutzer an. Um einen eigenen GitLab Runner auf Ihrem Rechner oder auf Ihrem Server aufzusetzen, folgen Sie der offiziellen GitLab Runner Anleitung (wird in neuem Tab geöffnet).

Damit wir den temporären Zugriff einrichten können, müssen Sie sich vorher einen GitHub Account anlegen und mit diesem einmal an git.rwth-aachen.de (wird in neuem Tab geöffnet) anmelden.
Beim Loginversuch bekommt Sie dann einen Fehler "Email has already been taken" angezeigt.

Sie müssen beim Erstellen des GitHub-Accounts bitte unbedingt darauf achten, dass Sie dieselbe E-Mail-Adresse verwenden wie bei ihrem GitLab-Account.
Senden Sie anschließend nach dem Loginversuch die folgenden Daten an das IT-ServiceDesk (wird in neuem Tab geöffnet):

• Ihren Benutzernamen
• Ihre GitLab-Kennung
• verwendetete E-Mail-Adresse

Wir werden dann die beiden Accounts verknüpfen und somit einen temporären Zugriff ermöglichen.

Um die fehlenden Bilder wieder herzustelllen, müssen Sie wie folgt vorgehen:

1. Wiki Repo klonen (in der GUI unter Wiki→oben rechts "Repository klonen", dann den angezeigten Befehl ausführen)
2. Repo exportieren (in der GUI unter Einstellungen → Allgemein → Erweiter → Export project)
3. Den generierten Export entpacken

4. die Dateien und Verzeichnisse aus dem Ordner uploads aus dem Export in das Verzeichnis uploads des lokal geklonten Wikis kopieren und pushen

   cp -r <path_to_extracted_.tar.gz>/uploads <path_to_repo_clone>/uploads cd <path_to_repo_clone> git add . git commit -am"Fix missing images" git push

5. In allen *.md Dateien die Pfade anpassen, und gleichzeitig ein Backup machen:

   find . -type f -iname'*.md' -exec sed -i.bak's#/uploads#uploads#g' "{}" +;

6. Nun die geänderten Dateien wieder ins Repository "pushen". Dabei die .bak-Dateien ignorieren

   git commit -am"Changed URLs to images" git push

7. Wiki in der GUI überprüfen

Wenn Sie sich zwei Jahre lang nicht bei Ihrem Konto angemeldet haben, wird Ihr Konto deaktiviert, und Sie erhalten eine E-Mail mit dem Betreff “Your Account has been deactivated”.

Um Ihr Konto wieder zu aktivieren, müssen Sie sich einmal bei GitLab anmelden.

Für einen kurzen Zeitraum können git-ce und git.rwth weiterhin genutzt werden.

Der genaue Zeitpunkt für die Migration von git-ce wird noch festgelegt. Sobald ein Termin feststeht, informieren wir Sie rechtzeitig.

Bitte beachten Sie bei der Migration von git.rwth nach git.nrw, dass bei git.nrw vergleichbare Nutzungsbedingungen gelten und die Quota-Regelungen nicht überschritten werden können.

Sollten Ihre Projekte dieses Quota überschreiten, ist vor bzw. im Rahmen der Migration eine Erhöhung des Projektlimits möglich.

Bei Erhöhungsbedarf der Quota bei git.nrw verwenden Sie bitte das Kontaktformular (wird in neuem Tab geöffnet).

Dazu gibt es folgende Anleitungen:

Migration zu git.nrw

Migration in ein anderes GitLab (wird in neuem Tab geöffnet)

Bitte kontaktieren Sie den Owner des Projekts, in dem Sie kollaborieren. Dieser wird Ihnen sagen, in welches Zielsystem das Projekt migriert wird und zu welchem Zeitpunkt.

Wird das Projekt nach git.nrw migriert, so kann das git.nrw Gästemanagement genutzt werden. Eine Anleitung finden Sie auf der Seite Gäste zu git.nrw einladen.

Ja, eine aktuelle Anleitung zu DOIs in GitLab finden Sie auf der Seite DOIs für GitLab-Repositories zuweisen (wird in neuem Tab geöffnet).

Die Funktion Keep latest artifacts wurde deaktiviert, um die Speicherauslastung in GitLab nachhaltig zu steuern und exzessiven Platzverbrauch durch veraltete oder unnötige Artefakte zu vermeiden.

Bisher wurden die zuletzt erstellten Artefakte (z. B. Builds, Releases) automatisch beibehalten, auch wenn sie älter als 90 Tage waren - unabhängig vom Standard-Löschzeitraum.

Ab sofort gilt der standardmäßige Löschzeitraum von 90 Tagen für alle Artefakte, auch für die zuletzt erstellten. 

Das bedeutet:

• Alle Artefakte, die älter als 90 Tage sind, werden automatisch gelöscht.
• Es gibt keine Ausnahme mehr für "neueste" Artefakte.

Falls Sie ein eigenes Ablaufdatum für Artefakte gesetzt haben, wie auf der Seite Artifacts with an expiry (wird in neuem Tab geöffnet) beschrieben, sind Sie von der Änderung nicht betroffen.