• 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
• 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

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

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.

Wie Shared Runner Jobs auswählen

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:

1. Job 1 wird zuerst ausgewählt, da es die niedrigste Jobnummer von Projekten ohne laufende Jobs (dh alle Projekte) hat.
2. 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).
3. 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).
4. 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.
5. 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.
6. 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>

1. Job 1 wird zuerst ausgewählt, da er die niedrigste Jobnummer von Projekten ohne laufende Jobs hat (d. h. alle Projekte).
2. Wir beenden Job 1.
3. 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.
4. 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).
5. Wir beenden Job 4.
6. Job 5 ist der nächste, da nach Abschluss von Job 4 in Projekt 2 keine Jobs mehr ausgeführt werden.
7. Job 6 ist der nächste, da Projekt 3 das einzige Projekt ist, in dem noch keine Jobs ausgeführt werden.
8. 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:

1. Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
2. 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:

1. Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
2. 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:

1. Gehen Sie zu den Einstellungen der Gruppe > CI/CD und erweitern Sie den Abschnitt Runners.
2. Deaktivieren Sie im Bereich Freigegebene Läufer den Schalter Freigegebene Läufer für diese Gruppe aktivieren.
3. 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:

1. Installieren Sie GitLab Runner.
2. Gehe zu der Gruppe, für die der Runner arbeiten soll.
3. Gehen Sie zu Einstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
4. Notieren Sie die URL und das Token.
5. Registrieren Sie den Läufer.

Gruppenläufer anzeigen und verwalten

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.

1. Gehen Sie zu der Gruppe, in der Sie die Läufer anzeigen möchten.
2. Gehen Sie zu Einstellungen > CI/CD und erweitern Sie den Abschnitt Runners.

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

1. Gehen Sie zu der Gruppe, für die Sie den Runner entfernen oder pausieren möchten.
2. Gehen Sie zu Einstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
3. 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.
4. 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:

1. Runner installieren.
2. Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
3. Notieren Sie die URL und das Token.
4. 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:

1. Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
2. 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:

1. Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Läufer.
2. Suchen Sie den Läufer, den Sie sperren oder entsperren möchten. Stellen Sie sicher, dass es aktiviert ist.
3. Klicken Sie auf die Schaltfläche Bleistift.
4. Aktivieren Sie die Option Zu aktuellen Projekten sperren.
5. 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:

1. Gehen Sie in einem Projekt zu Settings > CI/CD > Runners.
2. Wählen Sie Ihren speziellen Läufer aus, um die Einstellungen zu bearbeiten.
3. Geben Sie unter Maximum job timeout einen Wert ein.
4. Wählen Sie Änderungen speichern.

Funktionsweise dieser Funktion:

Beispiel 1 – Runner-Timeout größer als Projekt-Timeout

1. Sie legen das maximale Job-Timeout für einen Runner auf 24 Stunden fest
2. Sie legen das CI/CD-Timeout für ein Projekt auf 2 Stunden fest
3. Sie starten einen Job
4. Der Job läuft, wenn er länger läuft, nach 2 Stunden ab

Beispiel 2 – Runner-Timeout nicht konfiguriert

1. job-Timeout-Konfiguration von einem Runner aus
2. Sie setzen das CI/CD-Timeout für ein Projekt auf 2 Stunden
3. Sie starten einen Job
4. Der Job läuft, wenn er länger läuft, nach 2 Stunden ab

Beispiel 3 – Runner timeout kleiner als Projekt-Timeout

1. Sie legen das maximale Job-Timeout für einen Runner auf 30 Minuten fest
2. Sie legen das CI/CD-Timeout für ein Projekt auf 2 Stunden fest
3. Sie starten einen Job
4. 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

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:

1. Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
2. Suchen Sie den Runner, den Sie schützen oder aufheben möchten. Stellen Sie sicher, dass es aktiviert ist.
3. Klicken Sie auf die Schaltfläche Bleistift.
4. Aktivieren Sie die Option Geschützt.
5. 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:

1. Gehen Sie zu den Projekteinstellungen > CI/CD.
2. Erweitern Sie den Abschnitt Allgemeine Pipelineeinstellungen.
3. Suchen Sie das Runner-Token-Formularfeld und klicken Sie auf die Schaltfläche Wert anzeigen.
4. Löscht den Wert und speichert das Formular.
5. 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

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:

1. Besuchen Sie den Admin-Bereich > Übersicht > Runners.
2. 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.

1. Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
2. 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:

1. Gehen Sie zu den Projekteinstellungen > CI/CD und erweitern Sie den Abschnitt Runners.
2. Suchen Sie den Runner, für den Sie nicht markierte Jobs auswählen möchten, und stellen Sie sicher, dass er aktiviert ist.
3. Klicken Sie auf die Schaltfläche Bleistift.
4. Aktivieren Sie die Option Unmarkierte Jobs ausführen.
5. 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:

1. Der Runner ist so konfiguriert, dass er nur getaggte Jobs ausführt und hat das docker-Tag.
2. Ein Job mit einem hello -Tag wird ausgeführt und bleibt hängen.

Beispiel 2:

1. Der Runner ist so konfiguriert, dass er nur getaggte Jobs ausführt und hat das docker-Tag.
2. Ein Job mit einem docker-Tag wird ausgeführt und ausgeführt.

Beispiel 3:

1. Der Runner ist so konfiguriert, dass er nur getaggte Jobs ausführt und hat das docker-Tag.
2. 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:

1. Der Runner ist für die Ausführung von Jobs ohne Tags konfiguriert und hat das docker -Tag.
2. Ein Job ohne definierte Tags wird ausgeführt und ausgeführt.
3. Ein zweiter Job, der ein docker -Tag definiert hat, wird ausgeführt und ausgeführt.

Beispiel 2:

1. Der Runner ist für die Ausführung von Jobs ohne Tags konfiguriert und hat keine Tags definiert.
2. Ein Job ohne definierte Tags wird ausgeführt und ausgeführt.
3. 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

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:clonefetchundnone. 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: nonenormal 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

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

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

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 wird git clean nicht ausgeführt.

Zum Beispiel:

variables: GIT_CLEAN_FLAGS: -ffdx -e cache/script: - ls -al cache/

Git fetch zusätzliche Flags

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 wird git 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

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

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_DIRVerzeichnis 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_dirvon 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_PATHverwendet 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

Sie können die Anzahl der Versuche festlegen, die der laufende Job in den folgenden Schritten auszuführen versucht:

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

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"