1117
Kommentar:
|
2030
|
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. Wenn für einen Build keine Tags gesetzt werden, 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 den Deploy-Key "{{{Gitlab CI Linux-Pool Runner}}}" einbinden. | === 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}}} || {{{...}}} || |
Zeile 15: | Zeile 23: |
== Specific-Runner == Man kann auch eigene Specific-Runner erstellen, die dann nur die eigenen Projekte bedienen. Siehe [[https://about.gitlab.com/gitlab-ci/#gitlab-runner|hier]]. Zu empfehlen ist der [[https://github.com/ayufan/gitlab-ci-multi-runner|inoffizielle Go-Runner]], der schnell und unkompliziert auf gängigen Plattformen 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 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. Wenn für einen Build keine Tags gesetzt werden, wird ein zufälliger Shared-Runner benutzt.
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 |
... |
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. Siehe hier. Zu empfehlen ist der inoffizielle Go-Runner, der schnell und unkompliziert auf gängigen Plattformen eingerichtet werden kann.