Unterschiede zwischen den Revisionen 3 und 4
Revision 3 vom 2015-04-15 14:00:56
Größe: 1117
Autor: moenoel
Kommentar:
Revision 4 vom 2015-04-16 10:18:23
Größe: 1598
Autor: moenoel
Kommentar:
Gelöschter Text ist auf diese Art markiert. Hinzugefügter Text ist auf diese Art markiert.
Zeile 9: Zeile 9:
== Runner ==
Zeile 10: Zeile 11:
== Shared Runner == Runnser sind Prozesse, die die Builds/Test 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 "Specific"-Runner haben und dafür freigeschaltet sind (siehe die Option "{{{Allow shared runners}}}" in den Gitlab-CI-Projekteinstellungen). Da nicht alle Builds in allen Umgebungen funktionieren, kann via Tags gesteuert werden, welche Build-Scripte auf welchen Runnern ausgeführt werden können.
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 den Deploy-Key "{{{Gitlab CI Linux-Pool Runner}}}" einbinden. === Shared-Runner ===

Der FB3 stellt eine Reihe von "Shared"-Runnern zur Verfügung:

TODO -> Tabelle mit Runnern, Tags etc.; Auf Pool-Rechnern und anderem Kram installieren (Linux, Mac OS, Windows, Solaris, ...)
Zeile 15: Zeile 20:

== Specific-Runner ==

Man kann auch eigene Specific-Runner erstellen, die dann nur die eigenen Projekte bedienen... TODO

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 authorisiert werden, den Gitlab-Account nutzen zu dürfen.

Runner

Runnser sind Prozesse, die die Builds/Test 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 "Specific"-Runner haben und dafür freigeschaltet sind (siehe die Option "Allow shared runners" in den Gitlab-CI-Projekteinstellungen). Da nicht alle Builds in allen Umgebungen funktionieren, kann via Tags gesteuert werden, welche Build-Scripte auf welchen Runnern ausgeführt werden können.

Shared-Runner

Der FB3 stellt eine Reihe von "Shared"-Runnern zur Verfügung:

TODO -> Tabelle mit Runnern, Tags etc.; Auf Pool-Rechnern und anderem Kram installieren (Linux, Mac OS, Windows, Solaris, ...)

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... TODO

Dienste/Gitlab/CI (zuletzt geändert am 2021-11-05 13:27:31 durch manal)