TOC

Einrichten von Continuous Integration Pipelines mit GitLab CI unter Ubuntu 16.04

Einführung

GitLab Community Edition ist ein selbst gehosteter Git-Repository-Anbieter mit zusätzlichen Funktionen für das Projektmanagement und die Softwareentwicklung. Eine der wertvollsten Funktionen von GitLab ist das integrierte Tool für die kontinuierliche Integration und Bereitstellung mit dem Namen GitLab CI.

In diesem Handbuch wird gezeigt, wie Sie GitLab CI einrichten, um Ihre Repositorys auf Änderungen zu überwachen und automatisierte Tests auszuführen, um neuen Code zu validieren. Wir beginnen mit einer laufenden GitLab-Installation, in der wir ein Beispielrepository für eine grundlegende Node.js-Anwendung kopieren. Nach der Konfiguration unseres CI-Prozesses verwendet GitLab CI-Runner, um die Testsuite anhand des Codes in einem isolierten Docker-Container auszuführen, wenn ein neues Commit an das Repository gesendet wird.

Voraussetzungen

Bevor wir beginnen, müssen Sie eine erste Umgebung einrichten. Wir benötigen einen sicheren GitLab-Server, der konfiguriert ist, um unseren Code zu speichern und unsere CI / CD-Prozesse zu verwalten. Darüber hinaus benötigen wir einen Ort, an dem die automatisierten Tests ausgeführt werden. Dies kann entweder derselbe Server sein, auf dem GitLab installiert ist, oder ein separater Host. In den folgenden Abschnitten werden die Anforderungen ausführlicher behandelt.

Ein mit SSL gesicherter GitLab-Server

Um den Quellcode zu speichern und unsere CI / CD-Aufgaben zu konfigurieren, muss eine GitLab-Instanz auf einem Ubuntu 16.04-Server installiert sein. GitLab empfiehlt derzeit einen Server mit mindestens * 2 CPU-Kernen * und * 4 GB RAM *. Um Ihren Code vor Offenlegung oder Manipulation zu schützen, wird die GitLab-Instanz mithilfe von Let’s Encrypt mit SSL geschützt. Ihr Server muss über einen Domänennamen oder eine Unterdomäne verfügen, um diesen Schritt ausführen zu können.

Sie können diese Anforderungen mithilfe der folgenden Lernprogramme erfüllen:

Wir zeigen, wie Sie CI / CD-Läufer (die Komponenten, die die automatisierten Tests ausführen) für Projekte freigeben und für einzelne Projekte sperren können. Wenn Sie CI-Läufer für Projekte freigeben möchten, wird dringend empfohlen, öffentliche Anmeldungen einzuschränken oder zu deaktivieren. Wenn Sie Ihre Einstellungen während der Installation nicht geändert haben, gehen Sie zurück und folgen Sie https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-gitlab-on-ubuntu-16-04#restrict -oder-deaktivieren-öffentliche-Anmeldungen- (optional) [der optionale Schritt aus dem GitLab-Installationsartikel zum Einschränken oder Deaktivieren von Anmeldungen], um Missbrauch durch Dritte zu verhindern.

Ein oder mehrere Server, die als GitLab CI-Läufer verwendet werden sollen

GitLab CI Runners sind die Server, die den Code auschecken und automatisierte Tests ausführen, um neue Änderungen zu validieren. Um die Testumgebung zu isolieren, werden wir alle unsere automatisierten Tests in Docker-Containern ausführen. Dazu müssen wir Docker auf dem Server oder den Servern installieren, auf denen die Tests ausgeführt werden.

Dieser Schritt kann auf dem GitLab-Server oder auf einem anderen Ubuntu 16.04-Server ausgeführt werden, um zusätzliche Isolation bereitzustellen und Ressourcenkonflikte zu vermeiden. In den folgenden Lernprogrammen wird Docker auf dem Host installiert, auf dem Sie Ihre Tests ausführen möchten:

Wenn Sie bereit sind, fahren Sie mit dieser Anleitung fort.

Kopieren des Beispiel-Repositorys von GitHub

Zunächst erstellen wir in GitLab ein neues Projekt mit der Beispielanwendung Node.js. Wir werden das ursprüngliche Repository direkt von GitHub importieren, damit wir es nicht manuell hochladen müssen.

Melden Sie sich bei GitLab an und klicken Sie auf das * Plus-Symbol * in der oberen rechten Ecke und wählen Sie * Neues Projekt *, um ein neues Projekt hinzuzufügen:

image: https: //assets.digitalocean.com/articles/gitlab_ci_usage/new_project_icon_3.png [GitLab add new project icon]

Klicken Sie auf der neuen Projektseite auf die Registerkarte * Projekt importieren *:

Bild: https://assets.digitalocean.com/articles/gitlab_ci_usage/import-project.png [GitLab neuer Projektname]

Klicken Sie anschließend auf die Schaltfläche * Nach URL reponieren *. Obwohl es eine GitHub-Importoption gibt, ist ein persönliches Zugriffstoken erforderlich, mit dem das Repository und zusätzliche Informationen importiert werden. Wir interessieren uns nur für den Code und den Git-Verlauf, so dass der Import per URL einfacher ist.

Geben Sie im Feld * Git-Repository-URL * die folgende GitHub-Repository-URL ein:

https://github.com/do-community/hello_hapi.git

Es sollte so aussehen:

Bild: https://assets.digitalocean.com/articles/gitlab_ci_usage/new_project_github_url2.png [GitLab neues Projekt GitHub URL]

Da es sich um eine Demonstration handelt, ist es wahrscheinlich am besten, das Repository als "privat" zu kennzeichnen. Wenn Sie fertig sind, klicken Sie auf * Projekt erstellen *.

Das neue Projekt wird basierend auf dem von GitHub importierten Repository erstellt.

Grundlegendes zur Datei .gitlab-ci.yml

GitLab CI sucht in jedem Repository nach einer Datei mit dem Namen "+ .gitlab-ci.yml ", um zu bestimmen, wie der Code getestet werden soll. In dem von uns importierten Repository ist bereits eine " gitlab-ci.yml +" - Datei für das Projekt konfiguriert. Weitere Informationen zum Format finden Sie in der Referenzdokumentation zu .gitlab-ci.yml.

Klicken Sie in der GitLab-Oberfläche für das gerade erstellte Projekt auf die Datei "+ .gitlab-ci.yml +". Die CI-Konfiguration sollte folgendermaßen aussehen:

gitlab-ci.yml
image: node:latest

stages:
 - build
 - test

cache:
 paths:
   - node_modules/

install_dependencies:
 stage: build
 script:
   - npm install
 artifacts:
   paths:
     - node_modules/

test_with_lab:
 stage: test
 script: npm test

Die Datei verwendet die GitLab CI YAML-Konfigurationssyntax, um die auszuführenden Aktionen, die Reihenfolge, in der sie ausgeführt werden sollen, und die Bedingungen festzulegen, unter denen sie ausgeführt werden sollen. und die Ressourcen, die zum Ausführen der einzelnen Aufgaben erforderlich sind. Wenn Sie Ihre eigenen GitLab-CI-Dateien schreiben, können Sie einen Syntax-Linter aufrufen, indem Sie in Ihrer GitLab-Instanz auf "+ / ci / lint +" klicken, um zu überprüfen, ob Ihre Datei korrekt formatiert ist.

Die Konfigurationsdatei deklariert zunächst ein Docker-Image, mit dem die Testsuite ausgeführt werden soll. Da Hapi ein Node.js-Framework ist, verwenden wir das neueste Node.js-Image:

image: node:latest

Als Nächstes definieren wir explizit verschiedene kontinuierliche Integrationsstufen, die ausgeführt werden:

stages:
 - build
 - test

Die Namen, die Sie hier auswählen, sind willkürlich, aber die Reihenfolge bestimmt die Ausführungsreihenfolge für die folgenden Schritte. Stufen sind Tags, die Sie auf einzelne Jobs anwenden können. GitLab führt parallel Jobs derselben Stufe aus und wartet auf die Ausführung der nächsten Stufe, bis alle Jobs der aktuellen Stufe abgeschlossen sind. Wenn keine Stufen definiert sind, verwendet GitLab drei Stufen mit den Bezeichnungen "+ build", "+ test" und "+ deploy" und weist standardmäßig alle Jobs der Stufe "+ test +" zu.

Nach der Definition der Stufen enthält die Konfiguration eine "+ cache +" - Definition:

cache:
 paths:
   - node_modules/

Dies gibt Dateien oder Verzeichnisse an, die zwischen Läufen oder Phasen zwischengespeichert (für eine spätere Verwendung gespeichert) werden können. Dies kann dazu beitragen, die Zeit zu verkürzen, die zum Ausführen von Jobs benötigt wird, die auf Ressourcen angewiesen sind, die sich zwischen den Ausführungen möglicherweise nicht ändern. Hier wird das Verzeichnis + node_modules + zwischengespeichert, in dem + npm + die heruntergeladenen Abhängigkeiten installiert.

Unser erster Job heißt "+ install_dependencies +":

install_dependencies:
 stage: build
 script:
   - npm install
 artifacts:
   paths:
     - node_modules/

Jobs können beliebig benannt werden, aber da die Namen in der GitLab-Benutzeroberfläche verwendet werden, sind beschreibende Namen hilfreich. Normalerweise kann + npm install mit den nächsten Testphasen kombiniert werden. Um die Interaktion zwischen den Phasen besser zu demonstrieren, extrahieren wir diesen Schritt, um ihn in einer eigenen Phase auszuführen.

Wir kennzeichnen die Stage explizit als "build" mit der Direktive "+ stage ". Als nächstes geben wir die tatsächlichen Befehle an, die mit der Direktive " script " ausgeführt werden sollen. Sie können mehrere Befehle einfügen, indem Sie zusätzliche Zeilen in den Abschnitt " script +" einfügen.

Der Unterabschnitt "+ Artefakte " wird verwendet, um Datei- oder Verzeichnispfade anzugeben, die gespeichert und zwischen den Phasen übertragen werden sollen. Da mit dem Befehl " npm install " die Abhängigkeiten für das Projekt installiert werden, muss in unserem nächsten Schritt auf die heruntergeladenen Dateien zugegriffen werden. Durch die Angabe des Pfades " node_modules " wird sichergestellt, dass die nächste Stufe Zugriff auf die Dateien hat. Diese können nach dem Test auch in der GitLab-Benutzeroberfläche angezeigt oder heruntergeladen werden. Dies ist daher auch nützlich, um Artefakte wie Binärdateien zu erstellen. Wenn Sie alles speichern möchten, was während der Phase erzeugt wurde, ersetzen Sie den gesamten Abschnitt " path " durch " untracked: true +".

Schließlich deklariert der zweite Job mit dem Namen "+ test_with_lab +" den Befehl, der die Testsuite tatsächlich ausführt:

test_with_lab:
 stage: test
 script: npm test

Wir platzieren dies in der Stufe "+ test ". Da dies eine spätere Phase ist, hat es Zugriff auf die Artefakte, die in der Phase " build " erzeugt wurden, die in unserem Fall die Projektabhängigkeiten sind. Hier zeigt der Abschnitt " script +" die einzeilige YAML-Syntax, die verwendet werden kann, wenn nur ein einzelnes Element vorhanden ist. Wir hätten dieselbe Syntax auch im vorherigen Job verwenden können, da nur ein Befehl angegeben wurde.

Nachdem Sie eine grundlegende Vorstellung davon haben, wie die Datei "+ .gitlab-ci.yml +" CI / CD-Aufgaben definiert, können wir einen oder mehrere Läufer definieren, die in der Lage sind, den Testplan auszuführen.

Kontinuierlichen Integrationslauf auslösen

Da unser Repository eine "+ .gitlab-ci.yml +" - Datei enthält, wird bei jedem neuen Commit ein neuer CI-Lauf ausgelöst. Wenn keine Läufer verfügbar sind, wird der CI-Lauf auf "ausstehend" gesetzt. Bevor wir einen Läufer definieren, starten wir einen CI-Lauf, um zu sehen, wie ein Job im Status "Ausstehend" aussieht. Sobald ein Läufer verfügbar ist, nimmt er den ausstehenden Lauf sofort auf.

Klicken Sie in der Ansicht "+ hello_hapi +` GitLab project repository "auf das * Pluszeichen * neben dem Namen der Verzweigung und des Projekts und wählen Sie" Neue Datei "aus dem Menü aus:

image: https: //assets.digitalocean.com/articles/gitlab_ci_usage/new_file_button2.png [GitLab new file button]

Geben Sie auf der nächsten Seite "+ dummy_file +" in das Feld "Dateiname" ein und geben Sie Text in das Hauptbearbeitungsfenster ein:

image: https://assets.digitalocean.com/articles/gitlab_ci_usage/dummy_file2.png [GitLab-Dummy-Datei]

Klicken Sie unten auf * Commit changes * (Änderungen übernehmen), wenn Sie fertig sind.

Kehren Sie jetzt zur Hauptprojektseite zurück. Ein kleines * pausiertes * Symbol wird an das letzte Commit angehängt. Wenn Sie mit der Maus über das Symbol fahren, wird "Commit: pending" angezeigt:

image: https: //assets.digitalocean.com/articles/gitlab_ci_usage/pending_marker_2.png [GitLab-Markierung ausstehend]

Dies bedeutet, dass die Tests zur Überprüfung von Codeänderungen noch nicht ausgeführt wurden.

Um weitere Informationen zu erhalten, klicken Sie oben auf der Seite auf * Pipelines *. Sie werden zur Pipeline-Übersichtsseite weitergeleitet, auf der Sie sehen können, dass der CI-Lauf als ausstehend und als "steckengeblieben" markiert ist:

image: https: //assets.digitalocean.com/articles/gitlab_ci_usage/pipeline_index_stuck.png [GitLab-Pipeline-Index steckt fest]

Von hier aus können Sie auf den Status * ausstehend * klicken, um weitere Details zum Lauf zu erhalten. In dieser Ansicht werden die verschiedenen Phasen unseres Laufs sowie die einzelnen Jobs für jede Phase angezeigt:

image: https://assets.digitalocean.com/articles/gitlab_ci_usage/pipeline_detail_view.png [GitLab-Pipeline-Detailansicht]

Klicken Sie abschließend auf den Job * install_dependencies *. Dies gibt Ihnen die spezifischen Details darüber, was den Lauf verzögert:

image: https: //assets.digitalocean.com/articles/gitlab_ci_usage/job_detail_view.png [GitLab-Jobdetailansicht]

Hier zeigt die Nachricht an, dass der Job wegen eines Mangels an Läufern hängen bleibt. Dies wird erwartet, da wir noch keine konfiguriert haben. Sobald ein Läufer verfügbar ist, kann dieselbe Schnittstelle zum Anzeigen der Ausgabe verwendet werden. Hier können Sie auch Artefakte herunterladen, die während des Builds erstellt wurden.

Nachdem wir wissen, wie ein ausstehender Job aussieht, können wir unserem Projekt einen CI-Runner zuweisen, der den ausstehenden Job aufnimmt.

GitLab CI Runner Service installieren

Wir sind jetzt bereit, einen GitLab CI-Runner einzurichten. Dazu müssen wir das GitLab CI-Runner-Paket auf dem System installieren und den GitLab-Runner-Dienst starten. Der Dienst kann mehrere Runner-Instanzen für verschiedene Projekte ausführen.

Wie in den Voraussetzungen erwähnt, können Sie diese Schritte auf demselben Server ausführen, auf dem sich Ihre GitLab-Instanz befindet, oder auf einem anderen Server, um Ressourcenkonflikte zu vermeiden. Denken Sie daran, dass für die Konfiguration, die wir verwenden, Docker installiert sein muss, unabhängig davon, welchen Host Sie auswählen.

Der Installationsprozess des GitLab CI-Runner-Dienstes ähnelt dem Prozess, der zur Installation von GitLab selbst verwendet wird. Wir werden ein Skript herunterladen, um ein GitLab-Repository zu unserer + apt + Quellliste hinzuzufügen. Nach dem Ausführen des Skripts werden wir das Runner-Paket herunterladen. Wir können es dann konfigurieren, um unsere GitLab-Instanz zu bedienen.

Laden Sie zunächst die neueste Version des GitLab CI-Runner-Repository-Konfigurationsskripts in das Verzeichnis "+ / tmp +" herunter (dies ist ein anderes Repository als das, das vom GitLab-Server verwendet wird):

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh -o /tmp/gl-runner.deb.sh

Schauen Sie sich das heruntergeladene Skript an, um sicherzustellen, dass Sie mit den durchzuführenden Aktionen vertraut sind. Eine gehostete Version des Skripts hier finden Sie auch:

less /tmp/gl-runner.deb.sh

Wenn Sie mit der Sicherheit des Skripts zufrieden sind, führen Sie das Installationsprogramm aus:

sudo bash /tmp/gl-runner.deb.sh

Das Skript richtet Ihren Server für die Verwendung der von GitLab verwalteten Repositorys ein. Auf diese Weise können Sie GitLab-Runner-Pakete mit denselben Paketverwaltungstools verwalten, die Sie auch für Ihre anderen Systempakete verwenden. Sobald dies abgeschlossen ist, können Sie mit + apt-get mit der Installation fortfahren:

sudo apt-get install gitlab-runner

Dadurch wird das GitLab CI-Runner-Paket auf dem System installiert und der GitLab-Runner-Dienst gestartet.

Einrichten eines GitLab-Läufers

Als Nächstes müssen wir einen GitLab CI-Runner einrichten, damit er die Arbeit annehmen kann.

Dazu benötigen wir ein GitLab-Runner-Token, damit sich der Runner beim GitLab-Server authentifizieren kann. Die Art des benötigten Tokens hängt davon ab, wie wir diesen Läufer verwenden möchten.

Ein * projektspezifischer Läufer * ist nützlich, wenn Sie spezielle Anforderungen an den Läufer haben. Wenn in Ihrer Datei "+ gitlab-ci.yml +" beispielsweise Bereitstellungsaufgaben definiert sind, für die Anmeldeinformationen erforderlich sind, muss sich ein bestimmter Runner möglicherweise ordnungsgemäß bei der Bereitstellungsumgebung authentifizieren. Wenn Ihr Projekt ressourcenintensive Schritte im CI-Prozess enthält, ist dies möglicherweise auch eine gute Idee. Ein projektspezifischer Läufer akzeptiert keine Aufträge aus anderen Projekten.

Andererseits ist ein * freigegebener Läufer * ein Allzweckläufer, der von mehreren Projekten verwendet werden kann. Die Läufer nehmen Jobs aus den Projekten nach einem Algorithmus entgegen, der die Anzahl der Jobs berücksichtigt, die derzeit für jedes Projekt ausgeführt werden. Diese Art von Läufer ist flexibler. Sie müssen sich mit einem Administratorkonto bei GitLab anmelden, um gemeinsam genutzte Läufer einzurichten.

Im Folgenden wird gezeigt, wie Sie die Runner-Token für diese beiden Runner-Typen erhalten. Wählen Sie die Methode, die am besten zu Ihnen passt.

Sammeln von Informationen zum Registrieren eines projektspezifischen Läufers

Wenn Sie möchten, dass der Runner an ein bestimmtes Projekt gebunden ist, navigieren Sie zunächst zur Projektseite in der GitLab-Benutzeroberfläche.

Klicken Sie hier im linken Menü auf den Punkt * Einstellungen *. Klicken Sie anschließend im Untermenü auf den Eintrag * CI / CD *:

image: https: //assets.digitalocean.com/articles/gitlab_ci_usage/project_settings_item2.png [GitLab-Projekteinstellungselement]

Auf dieser Seite sehen Sie einen Abschnitt * Läufereinstellungen *. Klicken Sie auf die Schaltfläche * Erweitern *, um weitere Details anzuzeigen. In der Detailansicht wird auf der linken Seite erläutert, wie ein projektspezifischer Läufer registriert wird. Kopieren Sie das in Schritt 4 der Anleitung angezeigte Registrierungs-Token:

image: https://assets.digitalocean.com/articles/gitlab_ci_usage/specific_runner_config_settings2.png [GitLab-spezifische Runner-Konfigurationseinstellungen]

Wenn Sie aktive gemeinsam genutzte Läufer für dieses Projekt deaktivieren möchten, klicken Sie auf die Schaltfläche * Gemeinsam genutzte Läufer deaktivieren * auf der rechten Seite. Dies ist optional.

Wenn Sie bereit sind, fahren Sie fort, um zu erfahren, wie Sie Ihren Läufer anhand der Informationen registrieren, die Sie auf dieser Seite gesammelt haben.

Sammeln von Informationen zum Registrieren eines freigegebenen Läufers

Um die Informationen zu finden, die zum Registrieren eines freigegebenen Läufers erforderlich sind, müssen Sie mit einem Administratorkonto angemeldet sein.

Beginnen Sie mit einem Klick auf das Schraubenschlüsselsymbol in der oberen Navigationsleiste, um auf den Administratorbereich zuzugreifen. Klicken Sie im Abschnitt * Übersicht * des linken Menüs auf * Läufer *, um auf die Konfigurationsseite für gemeinsam genutzte Läufer zuzugreifen:

image: https: //assets.digitalocean.com/articles/gitlab_ci_usage/admin_area_icon2.png [GitLab-Administratorbereichssymbol]

Kopieren Sie das oben auf der Seite angezeigte Registrierungs-Token:

image: https: //assets.digitalocean.com/articles/gitlab_ci_usage/shared_runner_token2.png [GitLab shared runner token]

Mit diesem Token registrieren wir einen GitLab CI-Runner für das Projekt.

Registrieren eines GitLab CI Runner beim GitLab Server

Nachdem Sie ein Token haben, kehren Sie zu dem Server zurück, auf dem Ihr GitLab CI-Runner-Dienst installiert ist.

Geben Sie den folgenden Befehl ein, um einen neuen Läufer zu registrieren:

sudo gitlab-runner register

Sie erhalten eine Reihe von Fragen zur Konfiguration des Läufers:

Geben Sie den Domainnamen Ihres GitLab-Servers ein und verwenden Sie "+ https: // ", um SSL festzulegen. Sie können optional " / ci +" an das Ende Ihrer Domain anhängen, neuere Versionen werden jedoch automatisch umgeleitet.

  • Bitte gib den gitlab-ci Token für diesen Läufer ein *

Das Token, das Sie im letzten Abschnitt kopiert haben.

  • Bitte gib die gitlab-ci Beschreibung für diesen Läufer ein *

Ein Name für diesen bestimmten Läufer. Dies wird in der Liste der Läufer des Läuferdienstes in der Befehlszeile und in der GitLab-Benutzeroberfläche angezeigt.

  • Bitte geben Sie die gitlab-ci Tags für diesen Läufer ein (durch Kommas getrennt) *

Dies sind Tags, die Sie dem Läufer zuweisen können. GitLab-Jobs können Anforderungen in Bezug auf diese Tags ausdrücken, um sicherzustellen, dass sie auf einem Host mit den richtigen Abhängigkeiten ausgeführt werden.

Sie können dieses Feld in diesem Fall leer lassen.

  • Ob Runner für das aktuelle Projekt gesperrt werden soll [true / false] *

Weist den Läufer dem spezifischen Projekt zu. Es kann nicht von anderen Projekten verwendet werden.

Wählen Sie hier "false".

  • Bitte geben Sie den Testamentsvollstrecker ein *

Die vom Läufer zum Abschließen von Jobs verwendete Methode.

Wählen Sie hier "Docker".

  • Bitte geben Sie das Standard-Docker-Image ein (z. Rubin: 2.1) *

Das Standard-Image, das zum Ausführen von Jobs verwendet wird, wenn die Datei + .gitlab-ci.yml + keine Image-Spezifikation enthält. Geben Sie hier am besten ein allgemeines Bild an und definieren Sie spezifischere Bilder in Ihrer Datei "+ .gitlab-ci.yml +", wie wir es getan haben.

Als kleinen, sicheren Standard geben wir hier "alpine: latest" ein.

Nachdem Sie die Eingabeaufforderungen beantwortet haben, wird ein neuer Runner erstellt, mit dem Sie die CI / CD-Aufgaben Ihres Projekts ausführen können.

Sie können die Läufer anzeigen, über die der GitLab CI-Läufer-Service derzeit verfügt, indem Sie Folgendes eingeben:

sudo gitlab-runner list
OutputListing configured runners                          ConfigFile=/etc/gitlab-runner/config.toml
example-runner                                      Executor=docker Token=e746250e282d197baa83c67eda2c0b URL=https://example.com

Nachdem wir einen Läufer zur Verfügung haben, können wir in GitLab zum Projekt zurückkehren.

Anzeigen des CI / CD-Laufs in GitLab

Kehren Sie in Ihrem Webbrowser zu Ihrem Projekt in GitLab zurück. Abhängig davon, wie lange es her ist, seit Sie Ihren Läufer registriert haben, läuft der Läufer derzeit:

image: https: //assets.digitalocean.com/articles/gitlab_ci_usage/ci_running_icon_2.png [GitLab CI running icon]

Oder es könnte bereits abgeschlossen sein:

Bild: https://assets.digitalocean.com/articles/gitlab_ci_usage/ci_run_passed_icon_2.png

Unabhängig vom Status klicken Sie auf das Symbol * Wird ausgeführt * oder * Bestanden * (oder * Fehlgeschlagen *, wenn Sie auf ein Problem gestoßen sind), um den aktuellen Status des CI-Laufs anzuzeigen. Sie können eine ähnliche Ansicht erhalten, indem Sie auf das obere Menü * Pipelines * klicken.

Sie werden zur Pipeline-Übersichtsseite weitergeleitet, auf der Sie den Status des GitLab-CI-Laufs sehen können:

image: https://assets.digitalocean.com/articles/gitlab_ci_usage/pipeline_run_overview.png [GitLab CI-Pipeline-Ausführungsübersicht]

Unter der Überschrift * Stages * (Stufen) befindet sich ein Kreis, der den Status jeder Stufe im Lauf angibt. Wenn Sie auf die Bühne klicken, sehen Sie die einzelnen Jobs, die mit der Bühne verknüpft sind:

image: https://assets.digitalocean.com/articles/gitlab_ci_usage/pipeline_run_stage_view.png [GitLab CI-Pipeline Stage_view ausführen]

Klicken Sie auf den Job * install_dependencies * in der Phase * build *. Sie gelangen auf die Seite mit der Jobübersicht:

image: https://assets.digitalocean.com/articles/gitlab_ci_usage/pipeline_job_overview.png [Jobübersicht für GitLab CI-Pipeline]

Anstatt eine Meldung anzuzeigen, dass keine Läufer verfügbar sind, wird jetzt die Ausgabe des Jobs angezeigt. In unserem Fall bedeutet dies, dass Sie die Ergebnisse der Installation der einzelnen Pakete sehen können.

Auf der rechten Seite sehen Sie auch einige andere Elemente. Sie können andere Jobs anzeigen, indem Sie die * Phase * ändern und auf die unten aufgeführten Läufe klicken. Sie können auch alle durch den Lauf erzeugten Artefakte anzeigen oder herunterladen.

Fazit

In diesem Handbuch haben wir einer GitLab-Instanz ein Demonstrationsprojekt hinzugefügt, um die fortlaufenden Integrations- und Bereitstellungsfunktionen von GitLab CI zu demonstrieren. Wir haben erläutert, wie Sie eine Pipeline in "+ gitlab-ci.yml +" - Dateien definieren, um Ihre Anwendungen zu erstellen und zu testen, und wie Sie Jobs Stufen zuweisen, um deren Beziehung zueinander zu definieren. Anschließend haben wir einen GitLab-CI-Runner eingerichtet, um CI-Jobs für unser Projekt abzurufen, und gezeigt, wie Sie Informationen zu einzelnen GitLab-CI-Läufen finden.

Related