|
Größe: 2777
Kommentar:
|
Größe: 3058
Kommentar:
|
| Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
| Zeile 7: | Zeile 7: |
| Anmelden kann sich jeder Benutzer mit einem FB3 oder Uni-Account (über den LDAP-Tab) ([[Accounts|weitere Infos zu Accounts]]). Beim ersten Login wird automatisch ein Gitlab-Account angelegt. Dabei wird als initiale E-Mailadresse, an die Benachrichtigungen versendet werden, {{{<Benutzer>@fb3.uni-bremen.de}}} gesetzt. | Anmelden kann sich jeder Benutzer mit einem FB3 oder [[Accounts|Uni-Account]] (über den LDAP-Tab) ([[Accounts|weitere Infos zu Accounts]]). Beim ersten Login wird automatisch ein Gitlab-Account angelegt. Dabei wird als initiale E-Mailadresse, an die Benachrichtigungen versendet werden, {{{<Benutzer>@fb3.uni-bremen.de}}} gesetzt. |
| Zeile 11: | Zeile 11: |
| Für den Zugriff auf von Gitlab verwaltete Repositories wird ein [[https://www.informatik.uni-bremen.de/t/SSH|SSH-Schlüsselpaar]] benötigt. Der Public-Key kann in Gitlab via "My Profile -> SSH Keys" installiert werden. | Für den Zugriff auf von Gitlab verwaltete Repositories via SSH wird ein [[https://www.informatik.uni-bremen.de/t/SSH|SSH-Schlüsselpaar]] benötigt. Der Public-Key kann in Gitlab via "My Profile -> SSH Keys" installiert werden. |
| Zeile 25: | Zeile 25: |
| * Beim Pushen via HTTPS darf das Changeset nicht gößer als 5MB sein. Das ist ein Limit das sowohl vom Webserver als auch von Gitlab durchgesetzt wird. SSH hat diese Limitierung nicht. | * Beim Pushen via HTTPS darf das Changeset nicht größer als 20MB sein. Das ist ein Limit das sowohl vom Webserver als auch von Gitlab durchgesetzt wird. SSH hat diese Limitierung nicht. * Das Clonen von großen Repositories über HTTPS bricht nach einer Weile mit einer Fehlermeldung ab ([[https://gitlab.com/gitlab-org/gitlab-ce/issues/232|Gitlab-Issue #232]]). Als Workaround muss man zumindest für das initiale Clonen auf SSH ausweichen. |
Gitlab
Der FB3 bietet den Github-Klon Gitlab unter folgender URL an:
Anmelden kann sich jeder Benutzer mit einem FB3 oder Uni-Account (über den LDAP-Tab) (weitere Infos zu Accounts). Beim ersten Login wird automatisch ein Gitlab-Account angelegt. Dabei wird als initiale E-Mailadresse, an die Benachrichtigungen versendet werden, <Benutzer>@fb3.uni-bremen.de gesetzt.
Jeder Benutzer kann Standardmäßig bis zu 10 Projekte anlegen. Wenn das nicht ausreicht, kann das Limit problemlos angehoben werden. Dazu bitte eine E-Mail an <service AT informatik DOT uni-bremen DOT de> schicken.
Für den Zugriff auf von Gitlab verwaltete Repositories via SSH wird ein SSH-Schlüsselpaar benötigt. Der Public-Key kann in Gitlab via "My Profile -> SSH Keys" installiert werden.
Wichtig: Der SSH-Dienst des Servers, auf dem Gitlab gehostet wird, unterstützt nur SSH-Schlüssel bis zu einer Länge von 4096 Bit. Längere Schlüssel führen zu einer permission denied Meldung.
Der RSA Fingerprint für den Server lautet 9b:1e:c6:c6:78:69:14:be:e9:5b:e7:24:09:32:78:47.
Bei Bedarf können auch Gitlab-Accounts für externe Benutzer angelegt werden. Dafür bitte eine Mail mit dem Namen, dem gewünschten Benutzernamen und der Mailadresse des Nutzers an <service AT informatik DOT uni-bremen DOT de> senden. Achtung: der Nutzername muss einen Punkt ('.') enthalten, um Namenskonflikte mit FB3-Accounts zu vermeiden (also z.B. otto.mustermann oder o.mustermann verwenden).
Hinweis: Bei Fragen oder Problemen mit Gitlab, bitte ein Ticket im Gitlab-Projekt aufmachen.
Bekannte Probleme
Bei der ersten Anmeldung mit einem LDAP-Account wird eine E-Mail mit einem Bestätigungslink versendet, der nicht funktioniert. (Gitlab-Issue #5490) Diese E-Mail kann einfach ignoriert werden.
Wenn man versucht, seine E-Mailadresse in Gitlab zu ändern, bekommt man eine E-Mail mit einem Bestätigungslink, der nicht funktioniert. (Gitlab-Issue #5568) Als Workaround kann man auf der Seite mit dem Fehler Confirmation token can't be blank seine alte E-Mailadresse in das Textfeld eingeben und dann "Resend confirmation instructions" klicken. Der link in der darauf folgenden Mail sollte dann funktionieren.
- Beim Pushen via HTTPS darf das Changeset nicht größer als 20MB sein. Das ist ein Limit das sowohl vom Webserver als auch von Gitlab durchgesetzt wird. SSH hat diese Limitierung nicht.
Das Clonen von großen Repositories über HTTPS bricht nach einer Weile mit einer Fehlermeldung ab (Gitlab-Issue #232). Als Workaround muss man zumindest für das initiale Clonen auf SSH ausweichen.