|
Größe: 1873
Kommentar:
|
Größe: 2511
Kommentar:
|
| Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
| Zeile 7: | Zeile 7: |
| 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 authorisiert werden, den Gitlab-Account nutzen zu dürfen. | 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. |
| Zeile 9: | Zeile 9: |
| == Runner == | |
| Zeile 10: | Zeile 11: |
| == Shared Runner == | Runner sind Prozesse, die die Builds/Tests (sog. Jobs) ausführen. Dabei ist zwischen "Shared" und "Specific" Runnern zu unterscheiden. Ein "Specific"-Runner bedient gezielt nur ein Projekt, während "Shared"-Runner alle Jobs abarbeiten, die keinen eigenen "Specific"-Runner haben und dafür freigeschaltet sind (siehe die Option "{{{Allow shared runners}}}" in den Gitlab-CI-Projekteinstellungen). Da nicht alle Jobs in allen Umgebungen funktionieren, kann mit Tags gesteuert werden, welche Jobs auf welchen Runnern ausgeführt werden können. Wenn für einen Job keine Tags definiert sind, wird ein zufälliger Shared-Runner benutzt. |
| Zeile 12: | Zeile 13: |
| Auf den Rechnern des Linux-Pool in der E0 des MZH laufen Gitlab-CI-Runner mit den Berechtigungen des lokalen Nutzers {{{gitlab_ci}}} im "shared"-Modus. Um diese nutzen zu können, muss man in den Einstellungen des jeweiligen Gitlab-CI-Projektes die Option {{{Allow run builds on shared runners}}} aktivieren und im Gitlab-Projekt folgenden SSH-Key als Deploy-Key installieren: | 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. |
| Zeile 14: | Zeile 15: |
| {{{ ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCyMfXH0T1b055MlGaPCbdDxlYA/YrE7MmH6V8RXL9KokU5JprfGmfE63MgvymO/rOtGzqC7O9JETgffIz/AlIe8mLGG4mvPA+lYk6txYvMf5pEfFZZAriG3yID6zKigBkDnXfSOQNG7JqJihFVsGAJF9Il53ejlglcjAAGUK6N6841LPk0SlR Rh735oiycdH+8f/jBw63lPbXaDlue6OCDlqtS5Y9cZChCv1Jz0k9qLF4wZQ8IRhXM5MFccK4Qk1Z+i1UcCUuGHIe2EQ69kfDfpHx33y1OcAt/iWB8QvOnptkrx2jMCZTNAWblRV49MNa3unFQosAwlk9rX3oqMfF+qmjlz/9rgJpH7pCrPhklec5r2FzsWMHhMKk8qivve+8RJTGx1BVtmS09Gs r3+pWxGSj6OyxBru7LllTuEsfVHNvWui6yVxIrNWFAXZmn7KaGac4gFv6rYkXrOMGV0hDV4Ped2HpFEoz4fQbtDli2R3kmy+fiqYuuK1zHj+IH2hXrhAN5ESKatZorhRI9MiZvcZXJgIPqg9JYJZiORGmKKLEq5Rc6CXeWfudjf3GlXLxdaQZLJZEU1etT7rxFXbyV7EcyAftr30TXuXlcEZnU8 ZZFt9MEDjN7MGKNUKf36WQ9JVNPynzGX+Is4LB86GSWr7eKr4xo+TB22moiIETc2w== Gitlab-CI-Runner Linux-Pool }}} |
=== Shared-Runner === Der FB3 stellt eine Reihe von "Shared"-Runnern zur Verfügung: || '''Platform''' || '''Tags''' || '''Hostnamen''' || || Debian Wheezy || {{{linux}}} || {{{x{01..25}}}} || || Mac OS X || {{{darwin}}} || {{{a{01..20}}}} || || Smartos/Illumos|| {{{sunos}}} || {{{gitlab-ci-runner-sunos-1}}} || |
| Zeile 22: | Zeile 25: |
== 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 kann. Siehe die [[https://about.gitlab.com/gitlab-ci/#gitlab-runner|offizielle Dokumentation]] zu Gitlab-CI-Runnern. Zu empfehlen ist der [[https://github.com/ayufan/gitlab-ci-multi-runner|inoffizielle Go-Runner]], der schnell und unkompliziert auf gängigen Plattformen (Linux, Windows, Mac) eingerichtet werden kann. |
Gitlab Continuous Integration
Passend zu Gitlab bietet der FB3 den zugehörigen CI-Dienst Gitlab-CI unter folgender URL an:
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.
Runner
Runner sind Prozesse, die die Builds/Tests (sog. Jobs) ausführen. Dabei ist zwischen "Shared" und "Specific" Runnern zu unterscheiden. Ein "Specific"-Runner bedient gezielt nur ein Projekt, während "Shared"-Runner alle Jobs abarbeiten, die keinen eigenen "Specific"-Runner haben und dafür freigeschaltet sind (siehe die Option "Allow shared runners" in den Gitlab-CI-Projekteinstellungen). Da nicht alle Jobs in allen Umgebungen funktionieren, kann mit Tags gesteuert werden, welche Jobs auf welchen Runnern ausgeführt werden können. Wenn für einen Job keine Tags definiert sind, wird ein zufälliger Shared-Runner benutzt.
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.
Shared-Runner
Der FB3 stellt eine Reihe von "Shared"-Runnern zur Verfügung:
Platform |
Tags |
Hostnamen |
Debian Wheezy |
linux |
x{01..25} |
Mac OS X |
darwin |
a{01..20} |
Smartos/Illumos |
sunos |
gitlab-ci-runner-sunos-1 |
Fehlende Pakete für Builds/Tests können auf Anfrage nachinstalliert werden. Dazu kann man einfach eine E-Mail an <service AT informatik DOT uni-bremen DOT de> senden.
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 kann. Siehe die offizielle Dokumentation zu Gitlab-CI-Runnern.
Zu empfehlen ist der inoffizielle Go-Runner, der schnell und unkompliziert auf gängigen Plattformen (Linux, Windows, Mac) eingerichtet werden kann.