|
Größe: 1873
Kommentar:
|
Größe: 1598
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 folgenden SSH-Key als Deploy-Key installieren: | === Shared-Runner === |
| 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 }}} |
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 22: | 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