Wie Sie GitLab Continuous Integration (CI) Pipelines auf Ubuntu 20.04 einrichten

Jeder Entwickler versteht, wie wichtig die Versionskontrolle für den Softwareentwicklungs-Lebenszyklus ist. Sie ermöglicht es mehreren Personen, gleichzeitig an einem einzigen Projekt zu arbeiten, wobei jede Person ihre eigene Kopie des Codes pflegt und entscheidet, wann sie diese mit dem Rest des Teams teilt. Um dies zu erreichen, nutzen Entwickler Git-Repositories, um bei der Versionskontrolle zu helfen. GitLab ist ein webbasiertes Git-Repository, das mehr als nur ein Versionskontrollwerkzeug ist. Es bietet darüber hinaus DevOps-Tools, Issue-Tracking, kontinuierliche Integration und Bereitstellung.

GitLab bietet drei Optionen zur Auswahl: GitLab Community Edition (CE), GitLab Enterprise Edition (EE) und GitLab SaaS. GitLab CE und GitLab EE sind selbstverwaltete Lösungen. Das bedeutet, dass Sie die GitLab-Instanz selbst herunterladen, installieren und verwalten. GitLab SaaS wird von GitLab Inc. gehostet. Sie müssen sich also keine Gedanken über die Installation von irgendetwas machen, um es zu nutzen. Sie müssen lediglich ein GitLab-Konto erstellen und loslegen.

In diesem Tutorial zeigen wir Ihnen, wie Sie Continuous-Integration-Pipelines mit GitLab CI einrichten, um Ihre Repositories auf Änderungen zu überwachen und automatisierte Tests auszuführen, um neuen Code zu validieren. Wir beginnen mit der Einrichtung eines Git-Repositories zum Hosten des Codes. Anschließend konfigurieren wir einen CI-Prozess zur Überwachung von Commits im Repository und initiieren einen CI-Runner, um die Tests in einem isolierten Docker-Container auszuführen.

Voraussetzungen

Zu Beginn benötigen Sie einen Server, auf dem die GitLab-Versionskontrollsoftware läuft. Sowohl die selbstverwaltete GitLab-Variante als auch GitLab SaaS können automatisierte Tests ausführen. In den kostenlosen SaaS-Optionen gibt es jedoch einige Einschränkungen hinsichtlich der Minuten und Ressourcen, die für Ihre Tests zur Verfügung gestellt werden. Sie haben mehr Freiheit, wenn Sie die selbstverwalteten Optionen nutzen, da Sie Ihrer GitLab-Instanz so viele Ressourcen zuweisen können, wie Sie möchten. Folgen Sie unserem Tutorial über das Hosten eigener Git-Repositories mit GitLab, um zu erfahren, wie Sie Ihre eigene GitLab-Instanz einrichten.

Sie benötigen mindestens einen Server, der als GitLab-CI-Runner dient. Wenn Sie möchten, können Sie jedoch auch weitere Server verwenden. Wenn Sie eine selbstverwaltete GitLab-Instanz eingerichtet haben, können Sie denselben Server verwenden, aber wir bevorzugen die Einrichtung eines separaten Servers für den CI-Runner. Dieses Tutorial über die Einrichtung Ihres Ubuntu-Servers ist ein guter Anfang.

Sie müssen Docker auf Ihren GitLab-CI-Runner-Servern installiert haben, um die Testumgebungen in Docker-Containern zu isolieren. Wir haben ein Tutorial über die Installation und den Betrieb von Docker auf Ubuntu, das Ihnen helfen kann, diese Anforderung zu erfüllen.

Jetzt, da wir alles haben, was wir brauchen, fangen wir an!

Schritt 1: Erstellen Sie ein Projekt auf einer GitLab-Instanz

Wir beginnen mit der Erstellung eines Projekt-Repositories auf GitLab. Wir werden dieses Tutorial auf einer Node.js-Anwendung aufbauen. Da wir die Projektdateien nicht von Grund auf neu erstellen möchten, GitLab bietet ein Tool zum Importieren von Projekten aus anderen Versionskontroll-Repositories an, das wir nutzen werden. Die Anwendung, die wir importieren, ist eine einfache „hello world“-App, die mit Express.js – einem minimalistischen Web-Framework für Node.js-Anwendungen erstellt wurde. Wir werden die Tests mit Mocha und Chai – dies sind JavaScript-Frameworks, die für Unit-Tests verwendet werden. Mocha ermöglicht asynchrones Testen, Testabdeckungsberichte und kann mit anderen Assertion-Bibliotheken kombiniert werden. Chai ist eine Assertion-Bibliothek. Sie kann mit jedem Test-Framework kombiniert werden; in unserem Fall werden wir Mocha mit Chai kombinieren.

Da Sie nun die Grundlagen unseres Projekts kennen, melden Sie sich bei Ihrer GitLab-Instanz an (entweder selbstverwaltet oder SaaS), klicken Sie auf das 'Plus'-Symbol in der oberen Navigationsleiste und wählen Sie 'Neues Projekt'. Optional können Sie, wenn Sie ganz nach oben auf der Startseite Ihres Kontos scrollen, auf die Schaltfläche 'Neues Projekt' klicken:

Klicken Sie auf der Seite für neue Projekte auf die Registerkarte Projekt importieren:

Klicken Sie auf der nächsten geöffneten Seite auf die Schaltfläche Repo by URL:

Es gibt zwar eine GitHub-Importoption, aber wir werden diese nicht verwenden, da sie ein persönliches Zugriffs-Token (Personal Access Token) erfordert. Wir müssen keine persönlichen Zugriffs-Token einrichten, da wir mit einem öffentlichen Repository arbeiten und der Import nur mit der URL unkompliziert ist.

Kopieren Sie danach die folgende URL und fügen Sie sie in das Feld „Git Repository URL“ ein:

Es sollte so aussehen:

Lassen Sie das Repository auf Privat und klicken Sie auf die Schaltfläche Projekt erstellen, wenn Sie fertig sind. Warten Sie einige Sekunden, bis das Projekt von GitHub importiert wurde. Es wird dann unter Ihren GitLab-Repositories angezeigt. GitLab importiert das Projekt mit denselben Details wie das GitHub-Repository-Projekt.

Schritt 2: Analysieren der .gitlab-ci.yml-Datei

GitLab CI scannt jedes Repository auf GitLab nach einer Datei namens .gitlab-ci.yml, um zu wissen, wie automatisierte Tests ausgeführt werden sollen. In dem soeben importierten Repository sehen Sie eine .gitlab-ci.yml-Datei unter den Projektdateien. Weitere Informationen zur GitLab CI yml finden Sie in deren offizieller Schlüsselwort-Referenz für die .gitlab-ci.yml-Dateidokumentation.

Klicken Sie in der GitLab-Repository-Benutzeroberfläche auf die .gitlab-ci.yml-Datei, um sie im Browser zu öffnen. Sie sollte so aussehen:

Beachten Sie die Einrückung der Zeilen. Die Datei folgt einer strengen GitLab CI YAML-Konfigurationssyntax, um die verschiedenen auszuführenden Aktionen in einer bestimmten Reihenfolge unter bestimmten Bedingungen zu definieren. Um sicherzustellen, dass Ihre Konfigurationsdateien korrekt sind, bietet GitLab ein Test-Utility zur Validierung an. In Ihrer GitLab-Instanz können Sie in Ihrem Projekt-Repository die CI-Lint-Benutzeroberfläche aufrufen, um Ihre .gitlab-ci.yml zu validieren. Klicken Sie auf CI/CD im linken Navigationsmenü und klicken Sie auf die CI-Lint-Schaltfläche auf der angezeigten Seite:

Die Direktiven in der Konfigurationsdatei werden im Folgenden besprochen.

• Basis-Docker-Image

Die erste Zeile in der Konfigurationsdatei deklariert ein Docker-Image, das zur Ausführung der Tests verwendet werden soll. Da wir eine Node.js-Anwendung erstellen, verwenden wir das neueste Node.js-Image:

• Stages

Dann definieren wir die verschiedenen Stages, die unsere Continuous-Integration-Tests durchlaufen sollen. Wir haben nur zwei Stages:

Bei der Definition der Stage-Namen sind Namen wie build oder test frei gewählt – Sie können jeden beliebigen Namen wählen. Sie müssen die Stages jedoch richtig anordnen, da dies den Ausführungsfluss bestimmt. In unserem Fall werden die Jobs in der build-Stage vor den Jobs in der test-Stage ausgeführt. Der GitLab Runner führt Jobs in derselben Stage parallel aus und wartet, bis alle Jobs abgeschlossen sind, bevor er mit der Ausführung der Jobs in der nächsten Stage beginnt.

• Cache

Eine cache-Definition wird eingefügt, um die Dateien und Verzeichnisse anzugeben, die für die spätere Verwendung zwischen den Job-Durchläufen zwischengespeichert oder gespeichert werden:

Die Definition von Caching hilft, die Zeit für die Ausführung von Jobs zu minimieren, die auf Ressourcen angewiesen sind, die sich zwischen den Durchläufen wahrscheinlich nicht ändern. Wir geben das Verzeichnis node_modules an, das zwischengespeichert werden soll. Dies ist das Verzeichnis, in dem npm die Abhängigkeiten für das Projekt installiert.

• Jobs

Wir haben zwei Jobs in der Konfiguration:

• install_dependencies

Bei der Benennung von Jobs können Sie jeden beliebigen Namen wählen. Es wird jedoch empfohlen, einen beschreibenden Namen zu wählen, da diese in der GitLab-Benutzeroberfläche verwendet werden – dies kann beim Debuggen hilfreich sein. Die meisten Konfigurationen im Web kombinieren npm install mit den Befehlen in der Test-Stage. Wir haben sie nur getrennt, um zu demonstrieren, wie Jobs interagieren, da dies ein recht kleines Projekt ist. Die stage-Direktive markiert diesen Job als build – er wird in der Build-stage.

Die script-Direktive gibt die Befehle an, die bei der Ausführung dieses Jobs ausgeführt werden sollen. Sie können mehrere Befehle angeben, indem Sie Zeilen innerhalb des script-Blocks hinzufügen. Natürlich müssen Sie darauf achten, richtig einzurücken, und die Reihenfolge berücksichtigen, in der die Skripte ausgeführt werden sollen.

Die artifacts-Direktive gibt Dateien oder Verzeichnispfade an, die gespeichert und zwischen den Stages geteilt werden sollen. Auch hier sei daran erinnert, dass die richtige Reihenfolge der Stages entscheidend ist, um sicherzustellen, dass andere Dateien das haben, was sie zur Ausführung benötigen. Der npm install-Befehl installiert die Abhängigkeiten im node_modules-Verzeichnis. Indem wir es in den Artifacts deklarieren, machen wir es für Jobs verfügbar, die in nachfolgenden Stages ausgeführt werden. Die Dateien werden auch in der GitLab-Benutzeroberfläche zur Verfügung gestellt, falls Sie sie herunterladen möchten.

• test_with_mocha

Dieser Job wird in der test-Stage ausgeführt. Da dieser Job nach dem Job in der build-Stage ausgeführt wurde, stehen die in der build-Stage deklarierten Artefakte (die die Abhängigkeiten für unsere App sind) der test-Stage zur Verfügung. Der Script-Block gibt die npm-Befehle an, um unsere Tests auszuführen. Wir starten zuerst unsere Anwendung und führen dann die Tests für die Anwendung aus. Das Ausführen dieser Befehle löst die Befehle aus, die im package.json-Script-Block-Abschnitt angegeben sind:
Damit sollten Sie ein grundlegendes Verständnis der .gitlab-ci.yml-Datei haben. Wir sagen grundlegend, weil dies nur eine statische hello world-App ist. Als Nächstes wollen wir sehen, wie wir einen neuen CI-Durchlauf auslösen können.

Schritt 3: Auslösen eines GitLab-CI-Durchlaufs

Es wird Sie freuen zu hören, dass, sobald Ihr Repository die .gitlab-ci.yml-Datei enthält, alle neuen Commits, die Sie dorthin pushen, einen neuen Continuous-Integration-Durchlauf auslösen. Im Fall von selbstverwalteten GitLab-Instanzen wird der CI-Durchlauf auf „ausstehend“ (pending) gesetzt, wenn Sie keinen GitLab-Runner konfiguriert haben.

GitLab SaaS bietet Benutzern einige Shared Runner, die ihre Jobs übernehmen und automatisch ausführen können. Dies ist nur möglich, wenn die Shared Runner frei sind und Sie Ihr Kontingent nicht überschritten haben. In GitLab SaaS können Sie wählen, ob Ihr Repository die shared runners verwenden soll oder nicht, indem Sie auf die Seite Settings > CI / CD Ihres Projekts gehen, wie im Screenshot unten gezeigt. Auf dieser Seite finden Sie auch Informationen zur Installation des GitLab-Runners, auf die wir im nächsten Schritt näher eingehen werden:

Nehmen wir nun eine kleine Änderung vor, um einen CI-Durchlauf auszulösen. Navigieren Sie zurück in Ihr node_pipeline-GitLab-Projekt-Repository:

Klicken Sie auf die oben hervorgehobene README.md-Datei, um sie anzuzeigen:

Klicken Sie auf die Schaltfläche ‘Edit’, um die Datei zur Bearbeitung im Browser zu öffnen, und fügen Sie etwas Text hinzu:

Sobald Sie Text hinzugefügt haben, scrollen Sie nach unten und klicken Sie auf die Schaltfläche Commit changes, um die Änderungen zu speichern. Sie können die Commit-Nachricht nach Belieben ändern. Sie wird als Titel in der GitLab-Benutzeroberfläche angezeigt, wenn die Pipeline ausgeführt wird. Wir haben sie als Update README.md belassen, da dies recht aussagekräftig ist:

Sobald Sie die Änderungen übertragen haben, kehren Sie zur Hauptprojektseite zurück. Sie werden ein kleines paused icon neben dem neuesten Commit bemerken. Wenn Sie mit der Maus über das Symbol fahren, wird Folgendes angezeigt: ‘Pipeline:pending’:

Das bedeutet, dass der CI-Durchlauf ausgelöst wurde. Die Tests wurden jedoch noch nicht ausgeführt. Klicken Sie im Navigationsmenü links auf CI/CD, und wählen Sie dann Pipelines. Dadurch wird eine Seite mit weiteren Details zur Pipeline geöffnet. Sie können sehen, dass die CI aussteht und als blockiert (stuck) markiert ist:

Um weitere Details zum Durchlauf zu erhalten, klicken Sie auf den Status pending. Sie sehen die folgende Ansicht, die die verschiedenen Stages des Durchlaufs und die mit jeder Stage verknüpften einzelnen Jobs anzeigt:

Sie können auch auf einzelne Jobs klicken, um deren genauere Details zu sehen, wie z. B. die Ursache für die Verzögerungen. Im Falle von fehlgeschlagenen Durchläufen sehen Sie hier, was zum Fehlschlagen des Jobs geführt hat:

Die Meldung weist darauf hin, dass der Job feststeckt, weil Sie keine aktiven Runner konfiguriert haben, die diesen Job ausführen können. Wir werden das im nächsten Schritt tun. Sobald Sie einen Runner zur Verfügung stellen, wird der Job automatisch ausgeführt. Wenn ein Job ausgeführt wird, sehen Sie die Ausgabe auf dieser Benutzeroberfläche sowie die anderen herunterladbaren Artefakte, die während der Ausführung des Jobs generiert wurden.

Schritt 4: Einrichten eines GitLab CI Runner-Dienstes

Es ist nun an der Zeit, den zweiten Server zu nutzen, den wir im Abschnitt Voraussetzungen dieses Tutorials angegeben haben. Wir werden auf diesem Server einen GitLab-Runner-Dienst installieren und einrichten. Sie können den Dienst so bereitstellen, dass er mehrere Runner-Instanzen für verschiedene Projekte auf GitLab ausführt.

Sie haben die Möglichkeit, den Runner auf demselben Server bereitzustellen, auf dem auch Ihre selbstverwaltete GitLab-Instanz gehostet wird. Um jedoch sicherzustellen, dass eine Instanz nicht durch Ressourcen eingeschränkt wird, ist es besser, eine separate CI-Runner-Instanz einzurichten. Unabhängig davon, für welche Konfiguration Sie sich entscheiden, muss Docker installiert sein, um die Testumgebungen zu isolieren.

Der Prozess zur Installation des GitLab CI Runners ist vergleichbar mit dem für die Installation der selbstverwalteten GitLab-Instanz. Wir beginnen mit dem Herunterladen eines Skripts, um das offizielle GitLab-Repository mit dem folgenden Befehl zu den apt-Quellen hinzuzufügen:

Geben Sie Ihr Root-Passwort ein, wenn Sie dazu aufgefordert werden. Als Nächstes können Sie den Befehl ausführen, um den neuesten GitLab CI Runner zu installieren:

Der obige Befehl installiert und registriert einen Runner-Dienst, der für Ihre Projekte bereitsteht.

Schritt 5: Registrierungs-Token erhalten und den GitLab Runner verknüpfen

Um einen GitLab CI Runner so einzurichten, dass er Jobs annimmt, benötigen Sie ein GitLab-Runner-Token. Dieses wird benötigt, damit sich der Runner bei Ihrer GitLab-Serverinstanz authentifizieren kann. Es gibt zwei Arten von Token, je nachdem, wie Sie den Runner verwenden möchten: projektspezifisch und gemeinsam genutzter Runner (Shared Runner).

Projektspezifische Runner sind anwendbar, wenn Sie einzigartige Anforderungen an den Runner haben. Wenn Sie beispielsweise Deployment-Definitionen in Ihrer gitlab-ci.yml mit eindeutigen Token haben, wird möglicherweise ein spezifischer Runner empfohlen, um sich korrekt in der Deployment-Umgebung zu authentifizieren. Ein weiterer Aspekt ist, ob Ihre Continuous-Integration-Phasen ressourcenintensive Prozesse beinhalten. In diesem Fall wäre ein projektspezifischer Runner ideal. Beachten Sie, dass ein projektspezifischer Runner keine Jobs von anderen Projekten annimmt.

Gemeinsam genutzte Runner (Shared Runners) sind universell einsetzbar und können von mehreren Projekten verwendet werden. Die auf GitLab Inc gehostete GitLab-SaaS-Instanz verfügt über einige Shared Runner, die Ihre Pipelines automatisch übernehmen, wie in Schritt drei erklärt. Runner übernehmen Jobs aus Ihren Konfigurationen basierend auf einem Algorithmus, der die Anzahl der derzeit für jedes Projekt ausgeführten Jobs berücksichtigt. Ein Shared Runner ist flexibler als ein spezifischer Runner. Er kann über das Admin-Konto der GitLab-Instanz konfiguriert werden. Sehen wir uns an, wie wir die Token für beide Runner erhalten können.

• Registrieren eines projektspezifischen Runners

Um einen projektspezifischen Runner zu registrieren, öffnen Sie Ihr Projekt in Ihrer GitLab-Instanz oder Ihrem GitLab-SaaS-Konto. Klicken Sie im Navigationsmenü auf der linken Seite auf Settings und wählen Sie die Option CI/CD:

Scrollen Sie danach nach unten zum Abschnitt Runners und klicken Sie auf die Schaltfläche, um den Abschnitt zu erweitern:

Die linke Seite erklärt, wie man einen projektspezifischen Runner registriert. Dies ist eine Ansicht der GitLab-SaaS-Instanz. Sie können auch automatische Runner mit Kubernetes konfigurieren, aber in diesem Tutorial richten wir den manuellen Runner ein:

Als Nächstes müssen Sie sich auf den Abschnitt konzentrieren, in dem Sie das Token für dieses Projekt erhalten. Bei einer selbstverwalteten GitLab-Instanz zeigt die URL die Domain des Servers an, auf dem Ihre GitLab-Instanz läuft:

Sie können die Shared Runner für dieses Projekt deaktivieren, indem Sie den Schalter im rechten Bereich umlegen, und zwar unter Shared Runners. Kopieren Sie dann den angezeigten Registrierungs-Token in Ihren Notizblock, da wir ihn später verwenden werden.

• Registrieren eines Shared Runners

Um einen Shared Runner zu registrieren, müssen Sie sich als Administrator bei Ihrer selbstverwalteten GitLab-Instanz anmelden. Um auf den Admin-Bereich zuzugreifen, klicken Sie auf das Schraubenschlüssel-Symbol im oberen Navigationsmenü:

Im Admin-Bereich klicken Sie auf Runners im Bereich Overview des linken Menüs. Dadurch wird eine Seite mit den Konfigurationsanweisungen für Shared Runners geöffnet:

Kopieren Sie den auf der rechten Seite angezeigten Registrierungs-Token unter Set up a shared Runner manually. Sie werden diesen Token im nächsten Schritt verwenden, um den Runner zu registrieren.

• Verknüpfen eines GitLab-CI-Runners mit einer GitLab-Instanz

In diesem Schritt verknüpfen Sie Ihre GitLab-Instanz mit dem CI-Runner. Melden Sie sich wieder auf dem Server an, auf dem Sie den GitLab-Runner-Dienst in Schritt vier installiert haben. Um den Registrierungsprozess für den Runner zu starten, geben Sie den folgenden Befehl in Ihrem Terminal ein:

Der Befehl stellt Ihnen eine Reihe von Fragen:

• Geben Sie die URL der GitLab-Instanz ein (z. B. https://gitlab.com/):

Geben Sie den Domänennamen Ihrer GitLab-Instanz an, und verwenden Sie https://, um SSL zu spezifizieren.

• Geben Sie den Registrierungs-Token ein:

Geben Sie Ihren Registrierungs-Token an. Hier wählen Sie aus, ob dieser Runner projektspezifisch oder geteilt (shared) sein soll. Sie können für beide Optionen nur einen der zuvor kopierten Token angeben.

• Geben Sie eine Beschreibung für den Runner ein:

Wählen Sie einen aussagekräftigen Namen für Ihren CI-Runner, da dieser in der Benutzeroberfläche der GitLab-Instanz angezeigt wird.

• Geben Sie einen Executor ein: custom, docker-ssh, parallels, virtualbox, docker, shell, ssh, docker+machine, docker-ssh+machine, kubernetes:

Hier werden Ihnen Optionen zur Auswahl eines Executors zur Ausführung der Jobs angeboten. Geben Sie Docker.

• Geben Sie Tags für den Runner ein (kommagetrennt):

Dies ist optional. Sie können beliebige Tag-Namen eingeben, z. B. Abhängigkeiten, die dieser Runner enthält. Sie können dieses Feld vorerst leer lassen.

• Geben Sie das Standard-Docker-Image ein (z. B. ruby:2.6):

Hier wird von Ihnen erwartet, dass Sie ein Standard-Mehrzweck-Image angeben, das zur Ausführung von Jobs verwendet wird, falls die gitlab-ci.yml-Datei kein Image angibt. Geben Sie alpine:latest ein, da es sich um ein kleines, vielseitiges und sicheres Image handelt. Drücken Sie die Eingabetaste, und der Runner wird automatisch registriert und gestartet:

Um die Liste der aktuell verfügbaren Runner anzuzeigen, geben Sie den folgenden Befehl ein:

Schritt 6: Bestätigen, dass der CI-Runner erfolgreich in GitLab verknüpft ist

Kehren Sie als Nächstes zu Ihrem Browser zurück und rufen Sie Ihre Projektseite in der GitLab-Instanz auf. Je nachdem, wie viele Minuten seit der Registrierung des Runners vergangen sind, sehen Sie möglicherweise, dass der Job gerade ausgeführt wird:

Oder er wurde bereits abgeschlossen:

Navigieren Sie danach zur Seite Pipelines entweder über das linke Menü CI/CD > Pipelines oder indem Sie auf das Symbol running, passed, oder failed klicken (falls die Pipeline Fehler aufgewiesen hat), um den Status des CI-Durchlaufs anzuzeigen. Hier sehen wir, dass eine der Phasen (Build-Phase) bestanden hat, während eine andere noch läuft:

Klicken Sie in der Tabelle unter der Überschrift Stages auf eines der Phasensymbole, um die zugehörigen Jobs anzuzeigen:

Klicken Sie dann im Pop-up auf einen Job, um Details anzuzeigen:

Der Job wurde ausgeführt, und Sie können den Fortschritt sehen, als der Befehl npm die Abhängigkeiten installierte. Auf der rechten Seite können Sie weitere zugehörige Informationen einsehen. Sie haben die Möglichkeit, die Artefakte des Jobs herunterzuladen. Sie können auch über das Dropdown-Menü zwischen den Phasen wechseln, um andere Jobs anzuzeigen.

Hier können Sie unsere Testfälle sehen, die angezeigt werden, wenn Sie den Job in der Testphase auswählen:

Verfügbare Runner

Klicken Sie im linken Menü auf Settings > CI/CD und erweitern Sie Runners-Bereich. Dort sollten Sie den Runner sehen, den Sie gerade registriert haben. Je nachdem, ob Sie ein projektspezifisches Token oder ein gemeinsames Token angegeben haben, wird der Runner im jeweiligen Bereich angezeigt.

Hier können Sie sehen, dass wir ein projektspezifisches Token registriert haben. Der Runner erscheint unter Spezifische Runner:

Fazit

In diesem Tutorial haben Sie gelernt, wie Sie Ihre Tests mit GitLab CI automatisieren können. Wir haben damit begonnen, ein Node.js-App-Projekt auf GitLab einzurichten. Das Projekt enthielt einige Testfälle und eine gitlab-ci.yml. Wir haben gelernt, dass GitLab die gitlab-ci.yml-Datei verwendet, um zu bestimmen, was zu tun ist, wenn sie ausgelöst wird. Eine gitlab-ci.yml-Datei ist lediglich eine Konfigurationsdatei, die Anweisungen zum Erstellen und Testen von Anwendungen enthält, geschrieben im YAML-Format, das ein GitLab CI Runner verstehen kann.

Es ist uns auch gelungen, einen GitLab CI Runner auf einem separaten Host einzurichten. Wir haben ihn so registriert, dass er Jobs von unseren GitLab-Instanzen übernimmt, wann immer ein Trigger vorliegt. Obwohl dies ein einfaches Projekt war, können Sie auf diesen Informationen aufbauen, um Pipelines für komplexe Projekte einzurichten. Die Schritte zum Hinzufügen eines Projekts zu GitLab und zum Verknüpfen eines GitLab CI Runners bleiben dieselben. Was sich ändert, sind die Anweisungen und Stages in der gitlab-ci.yml-Datei.

Viel Spaß beim Computing!