Runners in GitLab konfigurieren
- Arten von Runners
- Shared Runners
- Wie Shared Runners Jobs auswählen
- Shared Runners aktivieren
- Shared Runners deaktivieren
- Gruppenläufer
- Gruppenläufer erstellen
- Gruppenläufer anzeigen und verwalten
- Gruppenläufer anhalten oder entfernen
- Spezifische Runner
- Einen bestimmten Runner erstellen
- Einen bestimmten Runner für ein bestimmtes Projekt aktivieren
- Verhindern, dass ein bestimmter Runner für andere Projekte aktiviert wird
- Shared Runners
- Runner-Cache manuell löschen
- Maximale Job-Zeitüberschreitung für einen Runner festlegen
- Seien Sie vorsichtig mit vertraulichen Informationen
- Verhindern Sie, dass Runner vertrauliche Informationen preisgeben
- Gabeln
- Angriffsvektoren in Läufern
- Setzen Sie das Runner-Registrierungstoken für ein Projekt zurück
- Ermitteln Sie die IP-Adresse eines Läufers
- Ermitteln Sie die IP-Adresse eines gemeinsam genutzten Läufers
- Ermitteln Sie die IP-Adresse eines bestimmten Runners
- Verwenden Sie Tags, um die Anzahl der Jobs mithilfe des Runners zu begrenzen
- Runner führt nur getaggte Jobs aus
- runner darf unmarkierte Jobs ausführen
- Runner-Verhalten mit Variablen konfigurieren
- Git-Strategie
- Git-Submodulstrategie
- Git checkout
- Git clean Flags
- Git fetch extra Flags
- Flaches Klonen
- Benutzerdefinierte Build-Verzeichnisse
- Umgang mit Parallelität
- Verschachtelte Pfade
- Jobstadien Versuche
- Systemaufrufe nicht verfügbar auf GitLab.com gemeinsam genutzte Runner
- Artefakt- und Cache-Einstellungen
In GitLab CI/CD führen Runner den in .gitlab-ci.yml
definierten Code aus.Ein Runner ist ein leichter, hochskalierbarer Agent, der einen CI-Job über die Koordinator-API von GitLab CI / CD aufnimmt, den Job ausführt und das Ergebnis an die GitLab-Instanz zurücksendet.
Runner werden von einem Administrator erstellt und sind in der GitLab-Benutzeroberfläche sichtbar.Läufer können für bestimmte Projekte spezifisch oder für alle Projekte verfügbar sein.
Diese Dokumentation konzentriert sich auf die Verwendung von Runnern in GitLab.Wenn Sie GitLab Runner installieren und konfigurieren müssen, lesen Sie die GitLab Runner-Dokumentation.
- Arten von Läufern
- Shared Runners
- Wie Shared Runner Jobs auswählen
- Freigegebene Läufer aktivieren
- Freigegebene Runner deaktivieren
- Gruppenläufer
- Gruppen-Runner erstellen
- Gruppenläufer anzeigen und verwalten
- Anhalten oder Entfernen eines Gruppen-Runners
- Spezifische Runner
- Einen bestimmten Runner erstellen
- Einen bestimmten Runner für ein bestimmtes Projekt aktivieren
- Verhindern, dass ein bestimmter Runner für andere Projekte aktiviert wird
- Den Runner-Cache manuell löschen
- Maximales Job-Timeout für einen Runner festlegen
- Seien Sie vorsichtig mit sensiblen Informationen
- Verhindern, dass Läufer vertrauliche Informationen preisgeben
- Forks
- Angriffsvektoren in Läufern
- Setzen Sie das Runner-Registrierungstoken für ein Projekt zurück
- Ermitteln Sie die IP-Adresse eines Runners
- Ermitteln Sie die IP-Adresse eines freigegebenen Runners
- Ermitteln Sie die IP-Adresse eines bestimmten Runners
- Verwenden Sie Tags, um die Anzahl der Jobs zu begrenzen, die den Runner verwenden
- runner führt nur getaggte Jobs aus
- runner darf unmarkierte Jobs ausführen
- Runner-Verhalten mit Variablen konfigurieren
- Git strategy
- Git-Submodul-Strategie
- Git checkout
- Git clean flags
- Git fetch zusätzliche Flags
- Flaches Klonen
- Benutzerdefinierte Build-Verzeichnisse
- Umgang mit Parallelität
- Verschachtelte Pfade
- Job stages attempts
- Systemaufrufe nicht verfügbar auf GitLab.com geteilte Läufer
- Artefakt- und Cache-Einstellungen
Arten von Läufern
In der GitLab-Benutzeroberfläche gibt es drei Arten von Läufern, je nachdem, auf wen Sie zugreifen möchten:
- Freigegebene Läufer stehen allen Gruppen und Projekten in einer GitLab-Instanz zur Verfügung.
- Gruppenläufer stehen allen Projekten und Untergruppen einer Gruppe zur Verfügung.
- Bestimmte Läufer sind bestimmten Projekten zugeordnet.In der Regel werden bestimmte Runner für jeweils ein Projekt verwendet.
Shared Runners sind für jedes Projekt in einer GitLab-Instanz verfügbar.
Verwenden Sie Shared Runners, wenn Sie mehrere Jobs mit ähnlichen Anforderungen haben. Anstatt mehrere Läufer für viele Projekte im Leerlauf zu haben, können Sie einige Läufer haben, die mehrere Projekte abwickeln.
Wenn Sie eine selbstverwaltete Instanz von GitLab verwenden:
- Ihr Administrator kann Shared Runners installieren und registrieren, indem Sie zu den Einstellungen Ihres Projekts > CI/CD gehen, den Abschnitt Runners erweitern und auf Runner-Installationsanweisungen anzeigen klicken.Diese Anweisungen finden Sie auch in der Dokumentation.
- Der Administrator kann auch eine maximale Anzahl von freigegebenen Runner-Pipeline-Minuten für jede Gruppe konfigurieren.
Wenn Sie GitLab.com :
- Sie können aus einer Liste freigegebener Runner auswählen, die GitLab verwaltet.
- Die geteilten Läufer verbrauchen die in Ihrem Konto enthaltenen 5 Minuten.
Shared Runner verarbeiten Jobs mithilfe einer Fair usage Queue. Diese Warteschlange verhindert, dass Projekte Hunderte von Jobs erstellen und alle verfügbaren gemeinsam genutzten Runner-Ressourcen verwenden.
Der Fair Usage Queue-Algorithmus weist Jobs basierend auf den Projekten zu, die die geringste Anzahl von Jobs haben, die bereits auf gemeinsam genutzten Runnern ausgeführt werden.
Beispiel 1
Wenn diese Jobs in der Warteschlange stehen:
- Job 1 für Projekt 1
- Job 2 für Projekt 1
- Job 3 für Projekt 1
- Job 4 für Projekt 2
- Job 5 für Projekt 2
- Job 6 für Projekt 3
Der Fair usage Algorithmus weist Jobs in folgender Reihenfolge zu:
- Job 1 wird zuerst ausgewählt, da es die niedrigste Jobnummer von Projekten ohne laufende Jobs (dh alle Projekte) hat.
- Job 4 ist der nächste, da 4 jetzt die niedrigste Jobnummer von Projekten ohne laufende Jobs ist (in Projekt 1 wird ein Job ausgeführt).
- Job 6 ist der nächste, da 6 jetzt die niedrigste Jobnummer von Projekten ohne laufende Jobs ist (in den Projekten 1 und 2 werden Jobs ausgeführt).
- Job 2 ist der nächste, da es sich bei Projekten mit der niedrigsten Anzahl laufender Jobs (jeder hat 1) um die niedrigste Jobnummer handelt.
- Job 5 ist der nächste, da in Projekt 1 jetzt 2 Jobs ausgeführt werden und Job 5 die niedrigste verbleibende Jobnummer zwischen den Projekten 2 und 3 ist.
- Endlich ist Job 3 … weil es der einzige Job ist, der noch übrig ist.
Beispiel 2
Wenn sich diese Jobs in der Warteschlange befinden:
- Job 1 für Projekt 1
- Job 2 für Projekt 1
- Job 3 für Projekt 1
- Job 4 für Projekt 2
- Job 5 für Projekt 2
- Job 6 für Projekt 3
/p>
- Job 1 wird zuerst ausgewählt, da er die niedrigste Jobnummer von Projekten ohne laufende Jobs hat (d. h. alle Projekte).
- Wir beenden Job 1.
- Job 2 ist der nächste, da nach Abschluss von Job 1 in allen Projekten wieder 0 Jobs ausgeführt werden und 2 die niedrigste verfügbare Jobnummer ist.
- Job 4 ist der nächste, da bei Projekt 1, in dem ein Job ausgeführt wird, 4 die niedrigste Anzahl von Projekten ist, in denen keine Jobs ausgeführt werden (Projekte 2 und 3).
- Wir beenden Job 4.
- Job 5 ist der nächste, da nach Abschluss von Job 4 in Projekt 2 keine Jobs mehr ausgeführt werden.
- Job 6 ist der nächste, da Projekt 3 das einzige Projekt ist, in dem noch keine Jobs ausgeführt werden.
- Zuletzt wählen wir Job 3 … weil es wieder der einzige Job ist, der noch übrig ist.
Freigegebene Läufer aktivieren
Ein GitLab.com , shared Runners sind standardmäßig in allen Projekten aktiviert.
Auf selbstverwalteten Instanzen von GitLab muss ein Administrator sie installieren und registrieren.
Sie können auch freigegebene Runner für einzelne Projekte aktivieren.
So aktivieren Sie Shared Runners:
- Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
- Wählen Sie Freigegebene Runner für dieses Projekt aktivieren.
Freigegebene Runner deaktivieren
Sie können freigegebene Runner für einzelne Projekte oder für Gruppen deaktivieren.Sie müssen über Eigentümerberechtigungen für das Projekt oder die Gruppe verfügen.
So deaktivieren Sie gemeinsam genutzte Runner für ein Projekt:
- Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
- Wählen Sie im Bereich Freigegebene Läufer die Option Freigegebene Läufer für dieses Projekt aktivieren aus, damit der Schalter ausgegraut ist.
Freigegebene Runner werden für ein Projekt automatisch deaktiviert:
- Wenn die Einstellung für freigegebene Runner für die übergeordnete Gruppe deaktiviert ist, und
- Wenn das Überschreiben dieser Einstellung auf Projektebene nicht zulässig ist.
So deaktivieren Sie gemeinsam genutzte Runner für eine Gruppe:
- Gehen Sie zu den Einstellungen der Gruppe > CI/CD und erweitern Sie den Abschnitt Runners.
- Deaktivieren Sie im Bereich Freigegebene Läufer den Schalter Freigegebene Läufer für diese Gruppe aktivieren.
- Um freigegebene Runner für einzelne Projekte oder Untergruppen zu aktivieren, klicken Sie optional auf Projekte und Untergruppen zulassen, um die Gruppeneinstellung zu überschreiben.
Gruppenläufer
Verwenden Sie Gruppenläufer, wenn Sie möchten, dass alle Projekte in einer Gruppe Zugriff auf eine Reihe von Läufern haben.
Gruppieren und verarbeiten Sie Aufträge mithilfe einer FIFO-Warteschlange (First in, First out).
Gruppen-Runner erstellen
Sie können einen Gruppen-Runner für Ihre selbstverwaltete GitLab-Instanz oder für GitLab.com erstellen.So erstellen Sie einen Gruppenläufer:
- Installieren Sie GitLab Runner.
- Gehe zu der Gruppe, für die der Runner arbeiten soll.
- Gehen Sie zu Einstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
- Notieren Sie die URL und das Token.
- Registrieren Sie den Läufer.
Gruppenläufer anzeigen und verwalten
Eingeführt in GitLab 13.2.
Sie können alle Runner für eine Gruppe, ihre Untergruppen und Projekte anzeigen und verwalten.Sie können dies für Ihre selbstverwaltete GitLab-Instanz oder für GitLab.com tun.
- Gehen Sie zu der Gruppe, in der Sie die Läufer anzeigen möchten.
- Gehen Sie zu Einstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
-
Die folgenden Felder werden angezeigt.
Attribut Beschreibung Typ Einer oder mehrere der folgenden Zustände: freigegeben, gruppenspezifisch, gesperrt oder angehalten Runner-Token Token, das zur Identifizierung des Runners verwendet wird und das der Runner zur Kommunikation mit der GitLab-Instanz verwendet Beschreibung Beschreibung, die dem Runner beim Erstellen gegeben wurde Version GitLab Runner-Version IP-Adresse IP-Adresse des Hosts, auf dem der Runner registriert ist Projekte Anzahl der Projekte, denen der Runner zugewiesen ist Jobs Gesamtzahl der vom Runner ausgeführten Jobs Tags Dem Runner zugeordnete Tags Letzter Kontakt Zeitstempel, der angibt, wann die GitLab-Instanz den Runner zuletzt kontaktiert hat
Auf dieser Seite können Sie , pausieren und entfernen Sie Runner aus der Gruppe, ihren Untergruppen und Projekten.
Anhalten oder Entfernen eines Gruppen-Runners
Sie können einen Gruppen-Runner für Ihre selbstverwaltete GitLab-Instanz oder für GitLab.com anhalten oder entfernen.
- Gehen Sie zu der Gruppe, für die Sie den Runner entfernen oder pausieren möchten.
- Gehen Sie zu Einstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
- Klicken Sie auf Pause oder Runner entfernen.
- Wenn Sie einen Gruppenläufer anhalten, der von mehreren Projekten verwendet wird, wird der Läufer für alle Projekte angehalten.
- Aus der Gruppenansicht können Sie keinen Runner entfernen, der mehr als einem Projekt zugewiesen ist.Sie müssen es zuerst aus jedem Projekt entfernen.
- Klicken Sie im Bestätigungsdialog auf OK.
Spezifische Runner
Verwenden Sie bestimmte Runner, wenn Sie Runner für bestimmte Projekte verwenden möchten. Zum Beispiel, wenn Sie haben:
- Jobs mit spezifischen Anforderungen, wie ein Deploy-Job, der Anmeldeinformationen erfordert.
- Projekte mit viel CI-Aktivität, die davon profitieren können, von anderen Läufern getrennt zu sein.
Sie können einen bestimmten Runner einrichten, der von mehreren Projekten verwendet werden soll. Spezifische runnermuss für jedes Projekt explizit aktiviert werden.
Bestimmte Runner verarbeiten Aufträge mithilfe einer FIFO-Warteschlange (First in, First Out).
Einen bestimmten Runner erstellen
Sie können einen bestimmten Runner für Ihre selbstverwaltete GitLab-Instanz oder für GitLab.com erstellen.
Um einen bestimmten Runner zu erstellen:
- Runner installieren.
- Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
- Notieren Sie die URL und das Token.
- Registrieren Sie den Läufer.
Einen bestimmten Runner für ein bestimmtes Projekt aktivieren
Ein bestimmter Runner ist in dem Projekt verfügbar, für das er erstellt wurde. Ein Administrator kann einen bestimmten Runner aktivieren, um ihn auf weitere Projekte anzuwenden.
- Sie müssen über Eigentümerberechtigungen für das Projekt verfügen.
- Der spezifische Runner darf nicht gesperrt werden.
So aktivieren oder deaktivieren Sie einen bestimmten Runner für ein Projekt:
- Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
- Klicken Sie auf Für dieses Projekt aktivieren oder Für dieses Projekt deaktivieren.
Verhindern, dass ein bestimmter Runner für andere Projekte aktiviert wird
Sie können einen bestimmten Runner so konfigurieren, dass er „gesperrt“ ist und nicht für andere Projekte aktiviert werden kann.Diese Einstellung kann beim ersten Registrieren eines Läufers aktiviert, aber auch später geändert werden.
So sperren oder entsperren Sie einen Läufer:
- Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Läufer.
- Suchen Sie den Läufer, den Sie sperren oder entsperren möchten. Stellen Sie sicher, dass es aktiviert ist.
- Klicken Sie auf die Schaltfläche Bleistift.
- Aktivieren Sie die Option Zu aktuellen Projekten sperren.
- Klicken Sie auf Änderungen speichern.
Den Runner-Cache manuell löschen
Lesen Sie den Cache löschen.
Maximales Job-Timeout für einen Runner festlegen
Für jeden Runner können Sie ein maximales Job-Timeout festlegen. Dieses Timeout hat Vorrang, wenn es kleiner als das vom Projekt definierte Timeout ist.
Mit dieser Funktion können Sie verhindern, dass Ihr freigegebener Runner von einem Projekt mit Jobs mit einem langen Timeout (z. B. eine Woche) überlastet wird.
Wenn nicht konfiguriert, überschreiben Runner das Projekt-Timeout nicht.
Auf GitLab.sie können das Job-Timeout für freigegebene Runner jedoch nicht überschreiben und müssen das vom Projekt definierte Timeout verwenden.
So legen Sie das maximale Job-Timeout fest:
- Gehen Sie in einem Projekt zu Settings > CI/CD > Runners.
- Wählen Sie Ihren speziellen Läufer aus, um die Einstellungen zu bearbeiten.
- Geben Sie unter Maximum job timeout einen Wert ein.
- Wählen Sie Änderungen speichern.
Funktionsweise dieser Funktion:
Beispiel 1 – Runner-Timeout größer als Projekt-Timeout
- Sie legen das maximale Job-Timeout für einen Runner auf 24 Stunden fest
- Sie legen das CI/CD-Timeout für ein Projekt auf 2 Stunden fest
- Sie starten einen Job
- Der Job läuft, wenn er länger läuft, nach 2 Stunden ab
Beispiel 2 – Runner-Timeout nicht konfiguriert
- job-Timeout-Konfiguration von einem Runner aus
- Sie setzen das CI/CD-Timeout für ein Projekt auf 2 Stunden
- Sie starten einen Job
- Der Job läuft, wenn er länger läuft, nach 2 Stunden ab
Beispiel 3 – Runner timeout kleiner als Projekt-Timeout
- Sie legen das maximale Job-Timeout für einen Runner auf 30 Minuten fest
- Sie legen das CI/CD-Timeout für ein Projekt auf 2 Stunden fest
- Sie starten einen Job
- Der Job läuft, wenn er länger läuft, nach 30 Minuten ab
Seien Sie vorsichtig mit sensiblen Informationen
Wenn Sie mit einigen Runner-Executoren einen Job auf dem Runner ausführen können, können Sie erhalten Sie vollen Zugriff auf das Dateisystem und damit auf jeden Code, den es ausführt, sowie auf das Token des Runners. Bei gemeinsam genutzten Läufern bedeutet dies, dass jeder, der Jobs auf dem Läufer ausführt, auf den Code eines anderen zugreifen kann, der auf dem Läufer ausgeführt wird.
Da Sie außerdem Zugriff auf das Runner-Token erhalten, ist es möglicheinen Klon eines Runners zu erstellen und beispielsweise falsche Jobs zu senden.
Das oben Genannte lässt sich leicht vermeiden, indem Sie die Verwendung von freigegebenen Runnern auf großen öffentlichen GitLab-Instanzen einschränken, den Zugriff auf Ihre GitLab-Instanz steuern und sicherere Runner-Executoren verwenden.
Verhindern, dass Läufer vertrauliche Informationen preisgeben
Eingeführt in GitLab 10.0.
Sie können Läufer schützen, damit sie keine vertraulichen Informationen preisgeben.Wenn ein Runner geschützt ist, wählt er Jobs aus, die nur in geschützten Zweigen oder geschützten Tags erstellt wurden, und ignoriert andere Jobs.
Um einen Runner zu schützen oder aufzuheben:
- Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
- Suchen Sie den Runner, den Sie schützen oder aufheben möchten. Stellen Sie sicher, dass es aktiviert ist.
- Klicken Sie auf die Schaltfläche Bleistift.
- Aktivieren Sie die Option Geschützt.
- Klicken Sie auf Änderungen speichern.
Forks
Wenn ein Projekt gegabelt wird, kopiert es die Einstellungen der Jobs, die sich darauf beziehen. Dies bedeutet, dass, wenn Sie freigegebene Runner für ein Projekt eingerichtet haben und jemand dieses Projekt gabelt, die freigegebenen Runner Jobs dieses Projekts bedienen.
Angriffsvektoren in Läufern
Bereits kurz erwähnt, aber die folgenden Dinge von Läufern können ausgenutzt werden.Wir sind immer auf der Suche nach Beiträgen, die diese Sicherheitsüberlegungen mildern können.
Setzen Sie das Runner-Registrierungstoken für ein Projekt zurück
Wenn Sie der Meinung sind, dass ein Registrierungstoken für ein Projekt aufgedeckt wurde, sollten Sie es zurücksetzen. Ein Token kann verwendet werden, um einen anderen Läufer für das Projekt zu registrieren. Dieser neue Runner kann dann verwendet werden, um die Werte geheimer Variablen abzurufen oder Projektcode zu klonen.
Um das Token zurückzusetzen:
- Gehen Sie zu den Projekteinstellungen > CI/CD.
- Erweitern Sie den Abschnitt Allgemeine Pipelineeinstellungen.
- Suchen Sie das Runner-Token-Formularfeld und klicken Sie auf die Schaltfläche Wert anzeigen.
- Löscht den Wert und speichert das Formular.
- Erweitern Sie nach dem Aktualisieren der Seite den Abschnitt Registrierungseinstellungenund überprüfen Sie das Registrierungstoken – es sollte geändert werden.
Ab sofort ist das alte Token nicht mehr gültig und registriert keine neuen Runner mehr im Projekt. Wenn Sie Tools zum Bereitstellen und Registrieren neuer Runner verwenden, sollten die in diesen Tools verwendeten Token aktualisiert werden, um den Wert des neuen Tokens widerzuspiegeln.
Ermitteln Sie die IP-Adresse eines Runners
Eingeführt in GitLab 10.6.
Es kann nützlich sein, die IP-Adresse eines Runners zu kennen, damit Sie Probleme mit diesem Runner beheben können. GitLab speichert und zeigt die IP-Adresse an, indem es die Quelle der HTTP-Anforderungen anzeigt, die es beim Abfragen von Jobs an GitLab stellt. Wenn sich die Runner-IP ändert, wird sie automatisch in GitLab aktualisiert.
Die IP-Adresse für geteilte Läufer und bestimmte Läufer kann gefunden werdenverschiedene Orte.
Ermitteln Sie die IP-Adresse eines freigegebenen Runners
Um die IP-Adresse eines freigegebenen Runners anzuzeigen, benötigen Sie Administratorzugriff auf die GitLab-Instanz. Um dies festzustellen:
- Besuchen Sie den Admin-Bereich > Übersicht > Runners.
- Suchen Sie nach dem Namen in der Tabelle und Sie sollten eine Spalte für die IP-Adresse sehen.
Ermitteln Sie die IP-Adresse eines bestimmten Runners
Um die IP-Adresse eines Runners für ein bestimmtes Projekt zu finden, müssen Sie über Eigentümerberechtigungen für das Projekt verfügen.
- Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
- Auf der Detailseite sollten Sie eine Zeile für die IP-Adresse sehen.
Verwenden Sie Tags, um die Anzahl der Jobs zu begrenzen, die den Runner verwenden
Sie müssen einen Runner einrichten, um alle verschiedenen Arten von Jobs ausführen zu können, die in den Projekten auftreten können, für die er freigegeben wird. Dies wäre für große Mengen von Projekten problematisch, wenn es keine Tags gäbe.
GitLab CI-Tags sind nicht dasselbe wie Git-Tags. GitLab CI-Tags sind Läufern zugeordnet.Git-Tags sind Commits zugeordnet.
Indem Sie einen Runner für die Arten von Jobs markieren, die er verarbeiten kann, können Sie sicherstellen, dass Shared Runner nur die Jobs ausführen, für die sie ausgestattet sind.
Zum Beispiel haben wir bei GitLab Läufer mit rails
wenn sie die entsprechenden Abhängigkeiten enthalten, um Rails-Testsuiten auszuführen.
Wenn Sie einen Läufer registrieren, ist sein Standardverhalten nur picktagged jobs.To wenn Sie dies ändern, müssen Sie über Eigentümerberechtigungen für das Projekt verfügen.
Um einen Läufer dazu zu bringen, nicht markierte Jobs auszuwählen:
- Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
- Suchen Sie den Runner, für den Sie nicht markierte Jobs auswählen möchten, und stellen Sie sicher, dass er aktiviert ist.
- Klicken Sie auf die Schaltfläche Bleistift.
- Aktivieren Sie die Option Unmarkierte Jobs ausführen.
- Klicken Sie auf die Schaltfläche Änderungen speichern, damit die Änderungen wirksam werden.
Nachfolgend finden Sie einige Beispielszenarien für verschiedene Variationen.
runner führt nur getaggte Jobs aus
Die folgenden Beispiele veranschaulichen die möglichen Auswirkungen, wenn der Runner nur getaggte Jobs ausführt.
Beispiel 1:
- Der Runner ist so konfiguriert, dass er nur getaggte Jobs ausführt und hat das
docker
-Tag. - Ein Job mit einem
hello
-Tag wird ausgeführt und bleibt hängen.
Beispiel 2:
- Der Runner ist so konfiguriert, dass er nur getaggte Jobs ausführt und hat das
docker
-Tag. - Ein Job mit einem
docker
-Tag wird ausgeführt und ausgeführt.
Beispiel 3:
- Der Runner ist so konfiguriert, dass er nur getaggte Jobs ausführt und hat das
docker
-Tag. - Ein Job, für den keine Tags definiert sind, wird ausgeführt und bleibt hängen.
runner darf unmarkierte Jobs ausführen
Die folgenden Beispiele veranschaulichen die möglichen Auswirkungen der Runner-Einstellung auf getaggte und unmarkierte Jobs.
Beispiel 1:
- Der Runner ist für die Ausführung von Jobs ohne Tags konfiguriert und hat das
docker
-Tag. - Ein Job ohne definierte Tags wird ausgeführt und ausgeführt.
- Ein zweiter Job, der ein
docker
-Tag definiert hat, wird ausgeführt und ausgeführt.
Beispiel 2:
- Der Runner ist für die Ausführung von Jobs ohne Tags konfiguriert und hat keine Tags definiert.
- Ein Job ohne definierte Tags wird ausgeführt und ausgeführt.
- Ein zweiter Job, der ein
docker
-Tag definiert hat, bleibt hängen.
Runner-Verhalten mit Variablen konfigurieren
Sie können CI/CD-Variablen verwenden, um Runner-Git-Verhalten global oder für einzelne Jobs zu konfigurieren:
GIT_STRATEGY
GIT_SUBMODULE_STRATEGY
GIT_CHECKOUT
GIT_CLEAN_FLAGS
GIT_FETCH_EXTRA_FLAGS
-
GIT_DEPTH
(flaches Klonen) -
GIT_CLONE_PATH
(benutzerdefinierte Build-Verzeichnisse)
Sie können auch Variablen verwenden, um zu konfigurieren, wie oft ein Runnerversucht bestimmte Phasen der Auftragsausführung.
Git strategy
- Eingeführt in GitLab 8.9als experimentelles Feature.
-
GIT_STRATEGY=none
erfordert GitLab Runner v1.7+.
Sie können die GIT_STRATEGY
festlegen, die zum Abrufen des Repository-Inhalts verwendet wird, entweder global oder pro Job im Abschnitt variables
:
variables: GIT_STRATEGY: clone
s gibt drei mögliche Werte:clone
fetch
undnone
. Wenn nicht angegeben, verwenden Jobs die Pipeline-Einstellung des Projekts.
clone
ist die langsamste Option. Es klont das Repository für jeden Job von Grund auf neu und stellt sicher, dass die lokale Arbeitskopie immer makellos ist.Wenn ein vorhandener Arbeitsbaum gefunden wird, wird er vor dem Klonen entfernt.
fetch
ist schneller, da die lokale Arbeitskopie wiederverwendet wird (zurück zu clone
, falls nicht vorhanden). git clean
wird verwendet, um alle vom letzten Job vorgenommenen Änderungen rückgängig zu machen, und git fetch
wird verwendet, um Commits abzurufen, die nach dem letzten Job ausgeführt wurden.
fetch
erfordert jedoch Zugriff auf den vorherigen Arbeitsbaum. Dies funktioniert gut, wenn Sie den shell
oder docker
Executor verwenden, da diese versuchen, Arbeitsbäume beizubehalten und standardmäßig wiederzuverwenden.
Dies hat Einschränkungen bei der Verwendung des Docker Machine Executors.
Es funktioniert nicht für den kubernetes
Executor, aber ein Feature-Vorschlag existiert.Der kubernetes
Executor klont immer in ein temporäres Verzeichnis.
Eine Git-Strategie von none
verwendet auch die lokale Arbeitskopie, überspringt jedoch alle Gitoperationen, die normalerweise von GitLab ausgeführt werden. GitLab Runner Pre-Clone-Skripte werden ebenfalls übersprungen, falls vorhanden. Diese Strategie könnte bedeuten, dass Sie fetch
und checkout
Befehle zu Ihrem .gitlab-ci.yml
Skript hinzufügen müssen.
Es kann für Jobs verwendet werden, die ausschließlich mit Artefakten arbeiten, wie z. B. ein Deployment-Job.Git-Repository-Daten sind möglicherweise vorhanden, aber wahrscheinlich veraltet. Sie sollten nur auf Dateien klicken, die aus dem Cache oder Artefakten in die lokale Arbeitskopie gebracht wurden.
Git-Submodul-Strategie
Erfordert GitLab Runner v1.10+.
Die GIT_SUBMODULE_STRATEGY
Variable wird verwendet, um zu steuern, ob / wie Gitsubmodules beim Abrufen des Codes vor einem Build enthalten sind. Sie können sie global oder pro Job im Abschnitt variables
festlegen.
Es gibt drei mögliche Werte: none
normal
und recursive
:
-
none
bedeutet, dass Submodule beim Abrufen der projektcode. Dies ist der Standardwert, der dem Verhalten vor v1.10 entspricht. -
normal
bedeutet, dass nur die Submodule der obersten Ebene enthalten sind. Es ist äquivalent zu:git submodule syncgit submodule update --init
-
recursive
bedeutet, dass alle Submodule (einschließlich Submodule von Submodulen)enthalten sind. Diese Funktion benötigt Git v1.8.1 und höher. Wenn Sie aGitLab Runner mit einem Executor verwenden, der nicht auf Docker basiert, stellen Sie sicher, dass die Git-Version diese Anforderung erfüllt. Es ist äquivalent zu:git submodule sync --recursivegit submodule update --init --recursive
Damit diese Funktion korrekt funktioniert, müssen die Submodule konfiguriert werden (in .gitmodules
) entweder mit:
- der HTTP(S) URL eines öffentlich zugänglichen Repositorys oder
- einem relativen Pfad zu einem anderen Repository auf der gleiche GitLab-Server. Siehe theGit Submodule Dokumentation.
Git checkout
Eingeführt in GitLab Runner 9.3.
Die Variable GIT_CHECKOUT
kann verwendet werden, wenn GIT_STRATEGY
entweder aufclone
oder fetch
gesetzt ist, um anzugeben, ob eine git checkout
sollte ausgeführt werden. Wenn notspecified , ist der Standardwert true. Sie können sie global oder pro Job im Abschnittvariables
festlegen.
Wenn auf false
gesetzt, wird der Runner:
- beim Ausführen von
fetch
– aktualisiert das Repository und belässt die Arbeitskopie in der aktuellen Revision, - beim Ausführen von
clone
– klont das Repository und belässt die Arbeitskopie in der Standardverzweigung.
Wenn GIT_CHECKOUT
auf true
gesetzt ist, funktionieren sowohl clone
als auch fetch
auf die gleiche Weise.Der Runner checkt die Arbeitskopie einer Revision aus, die sich auf die CI-Pipeline bezieht:
variables: GIT_STRATEGY: clone GIT_CHECKOUT: "false"script: - git checkout -B master origin/master - git merge $CI_COMMIT_SHA
Git clean flags
Eingeführt in GitLab Runner 11.10
Die Variable GIT_CLEAN_FLAGS
wird verwendet, um das Standardverhalten vongit clean
nach dem Auschecken der Quellen. Sie können es global oder pro Job im Abschnittvariables
festlegen.
GIT_CLEAN_FLAGS
akzeptiert alle möglichen Optionen des git clean
Befehls.
git clean
ist deaktiviert, wenn GIT_CHECKOUT: "false"
angegeben ist.
Wenn GIT_CLEAN_FLAGS
ist:
- Nicht angegeben,
git clean
Flags standardmäßig-ffdx
. - Mit dem Wert
none
wirdgit clean
nicht ausgeführt.
Zum Beispiel:
variables: GIT_CLEAN_FLAGS: -ffdx -e cache/script: - ls -al cache/
Git fetch zusätzliche Flags
Eingeführt in GitLab Runner 13.1.
Die Variable GIT_FETCH_EXTRA_FLAGS
wird verwendet, um das Verhalten vongit fetch
zu steuern. Sie können es global oder pro Job im Abschnitt variables
festlegen.
GIT_FETCH_EXTRA_FLAGS
akzeptiert alle Optionen des git fetch
Befehls. GIT_FETCH_EXTRA_FLAGS
Flags werden jedoch nach den Standardflags angehängt, die nicht geändert werden können.
Die Standardflags sind:
- GIT_DEPTH.
- Die Liste der refspecs.
- Eine Fernbedienung mit dem Namen
origin
.
Wenn GIT_FETCH_EXTRA_FLAGS
ist:
- Nicht angegeben,
git fetch
Flags standardmäßig auf--prune --quiet
zusammen mit den Standardflags. - Mit dem Wert
none
wirdgit fetch
nur mit den Standardflags ausgeführt.
Die Standardflags sind beispielsweise --prune --quiet
, sodass Sie git fetch
ausführlicher gestalten können, indem Sie dies nur mit --prune
überschreiben:
variables: GIT_FETCH_EXTRA_FLAGS: --prunescript: - ls -al cache/
Die obige Konfiguration führt dazu, dass git fetch
auf diese Weise aufgerufen wird:
git fetch origin $REFSPECS --depth 50 --prune
Wobei $REFSPECS
ein Wert ist, der dem Runner intern von GitLab bereitgestellt wird.
Flaches Klonen
Eingeführt in GitLab 8.9als experimentelles Feature.
Sie können die Tiefe des Abrufs und Klonens mit GIT_DEPTH
angeben.GIT_DEPTH
macht einen flachen Klon des Repositorys und kann erheblich beschleunigen cloning.It kann für Repositorys mit einer großen Anzahl von Commits oder alten, großen Binärdateien hilfreich sein. Der Wert wird an git fetch
und git clone
übergeben.
In GitLab 12.0 und höher haben neu erstellte Projekte automatisch einen Standardwert git depth
von 50
.
Wenn Sie eine Tiefe von 1
verwenden und eine Warteschlange mit Jobs oder retryjobs haben, können Jobs fehlschlagen.
Das Abrufen und Klonen von Git basiert auf einer Referenz, z. B. einem Zweignamen, sodass Runner keinen bestimmten Commit-SHA klonen können. Wenn sich mehrere Jobs in der Warteschlange befinden oder Sie einen alten Job erneut versuchen, muss sich das zu testende Commit in der geklonten GitHub-Historie befinden. Ein zu kleiner Wert für GIT_DEPTH
kann es unmöglich machen, diese alten Commits auszuführen, und unresolved reference
wird in angezeigtob-Protokolle. Sie sollten dann überdenken, GIT_DEPTH
auf einen höheren Wert zu ändern.
Jobs, die auf git describe
basieren, funktionieren möglicherweise nicht korrekt, wenn GIT_DEPTH
gesetzt ist, da nur ein Teil des Git-Verlaufs vorhanden ist.
Um nur die letzten 3 Commits abzurufen oder zu klonen:
variables: GIT_DEPTH: "3"
Sie können es global oder pro Job im Abschnitt variables
festlegen.
Benutzerdefinierte Build-Verzeichnisse
Eingeführt in GitLab Runner 11.10.
Standardmäßig klont GitLab Runner das Repository in einem eindeutigen Unterpfad des$CI_BUILDS_DIR
Verzeichnisses. Für Ihr Projekt ist jedoch möglicherweise der Code in einem bestimmten Verzeichnis erforderlich (z. B. Go projects). In diesem Fall können Sie die Variable GIT_CLONE_PATH
angeben, um dem Runner das Verzeichnis mitzuteilen, in das das Repository geklont werden soll:
variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/project-nametest: script: - pwd
Die GIT_CLONE_PATH
muss immer innerhalb von $CI_BUILDS_DIR
liegen. Das in $CI_BUILDS_DIR
Verzeichnis hängt vom Executor und der Konfiguration der Runner ab.builds_dirsetting.
Dies kann nur verwendet werden, wenn custom_build_dir
in der Konfiguration von therunner aktiviert ist.Dies ist die Standardkonfiguration für die docker
und kubernetes
Executoren.
Umgang mit Parallelität
Ein Executor, der eine Parallelität größer als 1
verwendet, kann zu Fehlern führen. Mehrere Jobs arbeiten möglicherweise im selben Verzeichnis, wenn builds_dir
von Jobs gemeinsam genutzt wird.
Der Läufer versucht nicht, diese Situation zu verhindern. Es liegt am Administratorund Entwickler, um die Anforderungen der Konfiguration zu erfüllen.
Um dieses Szenario zu vermeiden, können Sie einen eindeutigen Pfad innerhalb von $CI_BUILDS_DIR
verwenden, da runner zwei zusätzliche Variablen enthält, die eine eindeutige ID
der Parallelität bereitstellen:
-
$CI_CONCURRENT_ID
: Eindeutige ID für alle Jobs, die innerhalb des angegebenen Executors ausgeführt werden. -
$CI_CONCURRENT_PROJECT_ID
: Eindeutige ID für alle Jobs, die innerhalb des angegebenen Executors und Projekts ausgeführt werden.
Die stabilste Konfiguration, die in jedem Szenario und auf jedem Executor gut funktionieren sollte, ist die Verwendung von $CI_CONCURRENT_ID
im GIT_CLONE_PATH
. Beispiel:
variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/project-nametest: script: - pwd
Die $CI_CONCURRENT_PROJECT_ID
sollte in Verbindung mit $CI_PROJECT_PATH
verwendet werden,da die $CI_PROJECT_PATH
einen Pfad eines Repositorys bereitstellt. Das heißt, group/subgroup/project
. Beispiel:
variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_PATHtest: script: - pwd
Verschachtelte Pfade
Der Wert von GIT_CLONE_PATH
wird einmal erweitert und das Verschachteln von Variablen innerhalb wird nicht unterstützt.
Sie definieren beispielsweise die beiden folgenden Variablen in Ihrer.gitlab-ci.yml
-Datei:
variables: GOPATH: $CI_BUILDS_DIR/go GIT_CLONE_PATH: $GOPATH/src/namespace/project
Der Wert von GIT_CLONE_PATH
wird einmal in$CI_BUILDS_DIR/go/src/namespace/project
erweitert und führt zu einem Fehlerweil $CI_BUILDS_DIR
nicht erweitert wird.
Job stages attempts
In GitLab eingeführt, erfordert es GitLab Runner v1.9+.
Sie können die Anzahl der Versuche festlegen, die der laufende Job in den folgenden Schritten auszuführen versucht:
Variable | Beschreibung |
---|---|
ARTIFACT_DOWNLOAD_ATTEMPTS |
Anzahl der Versuche, Artefakte herunterzuladen, die einen Job ausführen |
EXECUTOR_JOB_SECTION_ATTEMPTS |
In GitLab 12.10 und höher die Anzahl der Versuche, einen Abschnitt in einem Job nach einem No Such Container Fehler auszuführen (nur Docker Executor). |
GET_SOURCES_ATTEMPTS |
Anzahl der Versuche, Quellen abzurufen, die einen Job ausführen |
RESTORE_CACHE_ATTEMPTS |
Anzahl der Versuche, den Cache wiederherzustellen, der einen Job ausführt |
Der Standardwert ist ein einziger Versuch.
Beispiel:
variables: GET_SOURCES_ATTEMPTS: 3
Sie können sie global oder pro Job im Abschnitt variables
festlegen.
Systemaufrufe nicht verfügbar auf GitLab.com geteilte Läufer
GitLab.com geteilte Läufer laufen auf CoreOS. Dies bedeutet, dass Sie einige Systemaufrufe wie getlogin
aus der C-Standardbibliothek nicht verwenden können.
Artefakt- und Cache-Einstellungen
Eingeführt in GitLab Runner 13.9.
Artefakt- und Cache-Einstellungen steuern das Komprimierungsverhältnis von Artefakten und Caches.Verwenden Sie diese Einstellungen, um die Größe des von einem Auftrag erstellten Archivs anzugeben.
- In einem langsamen Netzwerk können Uploads für kleinere Archive schneller sein.
- In einem schnellen Netzwerk, in dem Bandbreite und Speicher keine Rolle spielen, können Uploads mit dem schnellsten Komprimierungsverhältnis schneller sein, obwohl das erzeugte Archiv größer ist.
Für GitLab-Seiten, die HTTP-Bereichsanforderungen bedienen, sollten Artikel die Einstellung ARTIFACT_COMPRESSION_LEVEL: fastest
verwenden, da nur unkomprimierte ZIP-Archive diese Funktion unterstützen.
Ein Messgerät kann auch aktiviert werden, um die Übertragungsrate für Uploads und Downloads bereitzustellen.
variables: # output upload and download progress every 2 seconds TRANSFER_METER_FREQUENCY: "2s" # Use fast compression for artifacts, resulting in larger archives ARTIFACT_COMPRESSION_LEVEL: "fast" # Use no compression for caches CACHE_COMPRESSION_LEVEL: "fastest"
Variable | Beschreibung |
---|---|
TRANSFER_METER_FREQUENCY |
Geben Sie an, wie oft die Übertragungsrate des Messgeräts gedruckt werden soll. Sie kann auf eine Dauer festgelegt werden (z. B. 1s oder 1m30s ). Eine Dauer von 0 deaktiviert das Messgerät (Standard). Wenn ein Wert festgelegt ist, zeigt die Pipeline eine Fortschrittsanzeige für Artefakt- und Cache-Uploads und -Downloads an. |
ARTIFACT_COMPRESSION_LEVEL |
Um das Kompressionsverhältnis einzustellen, stellen Sie auf fastest fast default slow oder slowest . Diese Einstellung funktioniert nur mit dem Fastzip-Archivierer, daher muss auch das GitLab Runner-Feature-Flag FF_USE_FASTZIP aktiviert sein. |
CACHE_COMPRESSION_LEVEL |
To adjust compression ratio, set to fastest fast default slow , or slowest . This setting works with the Fastzip archiver only, so the GitLab Runner feature flag FF_USE_FASTZIP must also be enabled. |