TOC

So richten Sie die fortlaufende Integration mit Buildbot unter Ubuntu 16.04 ein

Einführung

Buildbot ist ein auf Python basierendes kontinuierliches Integrationssystem zur Automatisierung von Softwareerstellungs-, Test- und Freigabeprozessen. In den vorherigen Tutorials haben wir installed Buildbot, https://www.digitalocean.com/ community / tutorials / how-to-create-systemd-unit-files-for-buildbot [erstellte systemd-unit-dateien], damit das Init-System des Servers die Prozesse verwalten kann, und https://www.digitalocean.com/community/tutorials / how-to-configure-buildbot-with-ssl-using-an-nginx-reverse-proxy [konfiguriert Nginx als Reverse-Proxy], um SSL-gesicherte Browseranforderungen an die Weboberfläche von Buildbot zu leiten.

In diesem Handbuch wird gezeigt, wie Sie ein kontinuierliches Integrationssystem einrichten, um automatisch neue Änderungen an einem Repository zu testen. Wir werden eine einfache Node.js-Anwendung verwenden, um den Testprozess und die erforderliche Konfiguration zu demonstrieren. Um unsere Testumgebung vom Buildbot-Host zu isolieren, erstellen wir ein Docker-Image, das als Buildbot-Worker ausgeführt wird. Anschließend konfigurieren wir den Buildbot-Master so, dass er das GitHub-Repository auf Änderungen überwacht und jedes Mal automatisch testet, wenn neue Änderungen erkannt werden.

Voraussetzungen

Um diesem Tutorial zu folgen, benötigen Sie:

Außerdem müssen Sie die folgenden Lernprogramme auf dem Server ausführen:

Wenn Sie diese Anforderungen erfüllt haben, können Sie beginnen.

Fork das Beispiel-Repository in GitHub

Bevor wir mit der Konfiguration von Buildbot beginnen, werfen wir einen Blick auf das Beispielrepository, das wir für dieses Handbuch verwenden werden.

Besuchen Sie in Ihrem Webbrowser die hello hapi-Anwendung auf GitHub, die wir zu Demonstrationszwecken verwenden werden. Diese Anwendung ist ein einfaches "Hallo Welt" -Programm mit einigen Unit- und Integrationstests, geschrieben in hapi, einem Node.js-Webframework.

Da dieses Beispiel zur Veranschaulichung einer Vielzahl von Continuous Integration-Systemen verwendet wird, stellen Sie möglicherweise fest, dass einige Dateien zum Definieren von Pipelines für andere Systeme verwendet werden. Für Buildbot definieren wir die Erstellungsschritte auf dem Server und nicht im Repository.

Später werden wir Webhooks für Buildbot in unserem Repository einrichten, damit Änderungen automatisch neue Tests auslösen. Im Moment müssen wir Ihre eigene Abzweigung für das Repository erstellen.

Klicken Sie auf die Schaltfläche * Gabel * in der oberen rechten Ecke des Bildschirms:

image: https://assets.digitalocean.com/articles/buildbot_usage_1604/fork_repository.png [GitHub-Gabel-Repository-Schaltfläche]

Wenn Sie Mitglied einer GitHub-Organisation sind, werden Sie möglicherweise gefragt, wo Sie das Repository aufteilen möchten:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/where_to_fork.png

Sobald Sie ein Konto oder eine Organisation ausgewählt haben, wird Ihrem Konto eine Kopie des Repository hinzugefügt:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/your_fork.png [GitHub your fork]

Sie verwenden die URL für Ihren Fork in der Buildbot-Konfiguration. Nachdem wir eine Repository-URL haben, können wir mit der Konfiguration von Buildbot beginnen.

Richten Sie Docker für Buildbot ein

Zunächst richten wir Docker so ein, dass Buildbot damit Builds ausführt. Zuerst müssen wir den Zugriff zwischen Docker und Buildbot konfigurieren. Anschließend müssen wir ein Docker-Image erstellen, das für unsere Container verwendet werden soll.

Konfigurieren Sie den Zugriff auf Docker für Buildbot

Wir müssen Buildbot und Docker erlauben, auf verschiedenen Ebenen zu kommunizieren.

Zunächst müssen wir sicherstellen, dass der Buildbot-Prozess Zugriff auf den Docker-Daemon hat. Wir können dies tun, indem wir den Benutzer * buildbot * zur Gruppe * docker * hinzufügen:

sudo usermod -aG docker buildbot

Diese neue Gruppe wird Buildbot beim nächsten Neustart des Buildbot-Masters zur Verfügung stehen, was wir später tun werden.

Wir müssen auch sicherstellen, dass Buildbot weiß, wie man mit Docker kommuniziert. Da Buildbot in Python geschrieben ist, nutzt es das https://docker-py.readthedocs.io/en/stable/ [+ docker-py + Python-Paket], anstatt Docker-Befehle direkt auszugeben.

Sie können + docker-py + installieren, indem Sie Folgendes eingeben:

sudo -H pip install docker-py

Schließlich müssen wir den Netzwerkzugriff von Containern auf das Hostsystem und die Außenwelt öffnen. Wir können dies tun, indem wir eine Ausnahme für die Schnittstelle "+ docker0 +" in unserer Firewall zulassen.

Ermöglichen Sie den Zugriff auf Datenverkehr von der Schnittstelle + docker0 +, indem Sie Folgendes eingeben:

sudo ufw allow in on docker0

Buildbot und Docker sollten nun in der Lage sein, effektiv miteinander zu kommunizieren.

Erstellen Sie ein Docker-Image zur Verwendung als Buildbot-Worker

Als Nächstes erstellen wir einen Docker-Container, der als Buildbot-Worker zum Ausführen unserer Tests verwendet wird. Buildbot kann Docker-Container dynamisch starten, um sie als Worker zu verwenden. Die Container müssen jedoch zunächst mit einigen Buildbot-Worker-Komponenten erstellt werden.

Glücklicherweise bietet das Buildbot-Projekt eine grundlegende Buildbot-Worker-Image, für die bereits alle Buildbot-spezifischen Anforderungen konfiguriert sind. Wir müssen dieses Image nur als Basis verwenden und die zusätzlichen Abhängigkeiten installieren, die für unser Projekt erforderlich sind.

In unserem Fall ist die beispielanwendung, die wir verwenden werden eine Node.js-Anwendung, daher müssen wir sicherstellen, dass Node.js im Image verfügbar ist.

Um unser Image zu definieren, erstellen und öffnen Sie eine Datei mit dem Namen "+ Dockerfile +" in Ihrem Home-Verzeichnis:

nano ~/Dockerfile

In dieser Datei stützen wir unser Image mit + FROM buildbot / buildbot-worker: master + vom Buildbot-Worker-Image ab. Danach können wir zum Benutzer + root wechseln, um Node.js zu installieren, und dann zum Benutzer` + buildbot` zurückkehren, um die eigentlichen Befehle auszuführen:

~ / Dockerfile

FROM buildbot/buildbot-worker:master

USER root
RUN curl -sL https://deb.nodesource.com/setup_8.x | bash -
RUN apt-get install -y nodejs
USER buildbot

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Sobald wir ein + Dockerfile haben, können wir unser Image daraus erstellen. Wir werden das Image "+ npm-worker +" aufrufen, um die zusätzlichen Abhängigkeiten zu beschreiben, die wir installiert haben:

docker build -t npm-worker - < ~/Dockerfile

Docker beginnt mit der Erstellung Ihres Images basierend auf den Befehlen, die wir in der + Dockerfile + beschrieben haben. Es ruft das Basis-Image und seine Abhängigkeitsebenen ab, installiert Node.js und speichert die resultierende Umgebung in einem Image mit dem Namen "+ npm-worker +".

Konfigurieren Sie den Buildbot-Master

Nachdem wir nun ein Docker-Image haben, können wir den Buildbot-Master so konfigurieren, dass er es verwendet.

Da wir einen völlig neuen Erstellungsprozess definieren und unsere Anpassungen an der Masterkonfiguration bis zu diesem Punkt minimal waren, werden wir unsere Konfiguration von vorne beginnen. Um den Verlust der aktuellen Informationen zu vermeiden, verschieben wir die Originaldatei in eine Sicherungsdatei:

sudo mv /home/buildbot/master/master.cfg /home/buildbot/master/master.cfg.bak

Zeigen Sie die Konfiguration der Sicherungsdatei an, damit wir einige wichtige Werte kopieren können, die in unserer neuen Konfiguration verwendet werden sollen:

sudo cat /home/buildbot/master/master.cfg.bak

Die wichtigen Teile, die wir in die neue Konfiguration übertragen möchten, sind die Benutzeranmeldeinformationen und Berechtigungen. Suchen Sie in der Ausgabe nach den Konfigurationsabschnitten, die mit + c ['www'] ['authz'] + und + c ['www'] ['auth'] + beginnen:

Output. . .
c['www']['authz'] = util.Authz(
       allowRules = [
               util.AnyEndpointMatcher(role="admins")
       ],
       roleMatchers = [
               util.RolesFromUsername(roles=['admins'], usernames=[''])
       ]
)
c['www']['auth'] = util.UserPasswordAuth({'': ''})
. . .

Kopieren Sie diese Zeilen und speichern Sie sie, damit Sie sie später referenzieren können. Wir werden diese Details zu unserer neuen Buildbot-Masterkonfiguration hinzufügen, um unsere Benutzer- und Authentifizierungseinstellungen beizubehalten.

Erstellen Sie nun eine neue "+ master.cfg +" - Datei, in der Sie das Verhalten unserer Buildbot-Instanz neu definieren können:

sudo nano /home/buildbot/master/master.cfg

In dieser Datei definieren wir unsere neue Buildbot-Masterkonfiguration.

Richten Sie eine grundlegende Projektkonfiguration ein

Die Buildbot-Konfigurationsdatei ist eigentlich ein Python-Modul, das auf Kosten einiger Komplexität große Flexibilität bietet.

Wir werden mit einer Grundkonfiguration beginnen. Fügen Sie die folgenden Zeilen in Ihre Datei ein:

/home/buildbot/master/master.cfg

# -*- python -*-
# ex: set filetype=python:
from buildbot.plugins import *


c = BuildmasterConfig = {}

# Basic config
c['buildbotNetUsageData'] = None
c['title'] = "Hello Hapi"
c['titleURL'] = "https://github.com//hello_hapi"
c['buildbotURL'] = "https:///"
c['protocols'] = {'pb': {'port': 9989}}

Der Anfang der Datei enthält einige Kommentare, die viele Texteditoren interpretieren können, um die Syntaxhervorhebung korrekt anzuwenden. Danach importieren wir alles aus dem Paket "+ buildbot.plugins +", damit wir die Werkzeuge zur Verfügung haben, um unsere Konfiguration zu erstellen.

Die Buildbot-Konfiguration wird alle durch ein Wörterbuch mit dem Namen "+ BuildmasterConfig " definiert. Daher setzen wir diese Variable zum Starten auf ein leeres Wörterbuch. Wir erstellen eine Kurzvariable mit dem Namen " c +", die auf dasselbe Wörterbuch festgelegt ist, um den in der gesamten Datei erforderlichen Schreibaufwand zu verringern.

Einige Dinge, die in der folgenden Konfiguration zu beachten sind:

  • + buildbot GetImageData ist auf` + None` gesetzt. Ändern Sie dies in die Zeichenfolge "" basic "", wenn Sie den Entwicklern Nutzungsdaten melden möchten.

  • Die Zeichen "+ title " und " titleURL +" geben den Projektnamen und das GitHub-Repository wieder. Verwenden Sie den Link zu Ihrer eigenen Gabelung.

  • + buildbotURL + wird auf den SSL-gesicherten Domainnamen des Buildbot-Masters gesetzt. Denken Sie daran, mit "+ https: // " zu beginnen und mit einem abschließenden Schrägstrich " / +" zu enden.

  • Im Gegensatz zu unserer letzten Konfiguration ist die "" - Protokolldefinition nicht an localhost gebunden. Wir müssen Verbindungen von Docker-Containern über das Docker-Bridge-Netzwerk ` docker0 +` zulassen.

Konfigurieren Sie den Docker Worker

Als nächstes müssen wir unseren Docker-Worker definieren. Buildbot verwendet Docker, um Mitarbeiter nach Bedarf bereitzustellen. Dazu muss es wissen, wie eine Verbindung zu Docker hergestellt wird und welches Image verwendet werden soll.

Fügen Sie am Ende der Datei Folgendes ein:

/home/buildbot/master/master.cfg

. . .

# Workers
c['workers'] = []
c['workers'].append(worker.DockerLatentWorker("npm-docker-worker", None,
                       docker_host='unix://var/run/docker.sock',
                       image='npm-worker',
                       masterFQDN=''))

Die Zeile + c ['workers'] = [] + zeigt eine grundlegende Konvention, die wir beim Durchlaufen der Konfiguration verwenden werden. Wir setzen einen Schlüssel im Konfigurationswörterbuch auf eine leere Liste. Anschließend fügen wir der Liste Elemente hinzu, um die tatsächliche Konfiguration zu implementieren. Dies gibt uns die Flexibilität, später weitere Elemente hinzuzufügen.

Um unseren Worker zu definieren, erstellen wir eine Worker.DockerLatentWorker-Instanz und hängen sie an die Worker-Liste an. Wir nennen diesen Worker "+ npm-docker-worker ", damit wir später in der Konfiguration darauf verweisen können. Wir setzen dann das " docker_host " auf den Docker-Socket-Speicherort und geben den Namen des von uns erstellten Docker-Images an (in unserem Fall " npm-worker "). Wir setzen " masterFQDN +" auf den Domainnamen unseres Buildbot-Masters, um sicherzustellen, dass der Container den Master unabhängig von den internen Hostnamen-Einstellungen des Servers erreichen kann.

Konfigurieren Sie einen Scheduler

Als nächstes definieren wir einen Scheduler. Buildbot verwendet Scheduler, um basierend auf den Änderungen, die es von Änderungsquellen oder Änderungs-Hooks erhält, zu entscheiden, wann und wie Builds ausgeführt werden sollen (wir werden später einen Änderungs-Hook konfigurieren).

Fügen Sie die folgende Konfiguration am Ende der Datei ein:

/home/buildbot/master/master.cfg

. . .

# Schedulers
c['schedulers'] = []
c['schedulers'].append(schedulers.SingleBranchScheduler(
               name="hello_hapi",
               change_filter=util.ChangeFilter(project='/hello_hapi', branch='master'),
               treeStableTimer=3,
               builderNames=["npm"]))

Wir verwenden dieselbe Methode, um unsere Konfiguration an eine leere Liste anzuhängen. In diesem Fall fügen wir eine Instanz von + schedulers.SingleBranchScheduler + hinzu. Auf diese Weise können wir einen einzelnen Zweig im Repository überwachen, was die Konfiguration vereinfacht.

Wir nennen den Scheduler "hello_hapi", um ihn richtig zu identifizieren. Wir definieren dann einen Änderungsfilter. Viele verschiedene Sätze von Änderungen aus verschiedenen Quellen können an einen Planer übergeben werden. Änderungsfilter definieren eine Reihe von Kriterien, die bestimmen, ob die betreffende Änderung von diesem bestimmten Scheduler verarbeitet werden soll. In unserem Fall filtern wir basierend auf dem Namen des Projekts, der vom GitHub-Webhook gemeldet wird, und dem Zweig, den wir sehen möchten.

Als nächstes setzen wir den + treeStableTimer +, der festlegt, wie lange auf weitere Änderungen gewartet werden soll, auf 3 Sekunden. Dies hilft zu verhindern, dass Buildbot viele kleine Builds für Änderungen in die Warteschlange stellt, die eng miteinander verbunden sind. Schließlich definieren wir die Namen der Builder, die verwendet werden sollen, wenn eine Änderung unseren Kriterien entspricht (wir definieren diesen Builder vorübergehend).

Konfigurieren Sie eine Build Factory für die Node.js-Projekte

Als Nächstes konfigurieren wir eine Build-Factory für die Verarbeitung von Node.js-Projekten. Eine Buildfactory ist dafür verantwortlich, die Schritte zu definieren, die zum Erstellen eines Projekts oder in unserem Falltest ausgeführt werden sollen. Dazu wird eine "+ util.BuildFactory +" - Instanz definiert und anschließend die auszuführenden sequenziellen Schritte hinzugefügt.

Fügen Sie am Ende Ihrer Datei Folgendes ein:

/home/buildbot/master/master.cfg

. . .

# Build Factories
npm_f = util.BuildFactory()
npm_f.addStep(steps.GitHub(repourl='git://github.com//hello_hapi.git', mode='full', method='clobber'))
npm_f.addStep(steps.ShellCommand(command=["npm", "install"]))
npm_f.addStep(steps.ShellCommand(command=["npm", "test"]))

Zunächst definieren wir eine Build-Factory mit dem Namen "+ npm_f ". Der erste Schritt, den wir hinzufügen, ist eine " steps.GitHub" -Instanz. Hier legen wir das Repository fest, das in den Builder heruntergeladen werden soll. Wir setzen den Modus "" auf "full" und die Methode "" auf "clobber", um unser Repository jedes Mal vollständig zu bereinigen, wenn wir neuen Code abrufen.

Der zweite und dritte Schritt, die wir hinzufügen, sind + steps.ShellCommand + - Objekte, die Shell-Befehle definieren, die während des Builds im Repository ausgeführt werden sollen. In unserem Fall müssen wir "+ npm install " ausführen, um die Abhängigkeiten des Projekts zu erfassen. Danach müssen wir " npm test" ausführen, um Ihre Testsuite auszuführen. Das Definieren der Befehle als Liste (+ [" npm "," install "] +) wird in den meisten Fällen empfohlen, um zu verhindern, dass die Shell unerwünschte Erweiterungen für Elemente innerhalb des Befehls vornimmt.

Konfigurieren Sie einen Builder

Sobald wir eine Build-Factory mit den hinzugefügten Schritten haben, können wir einen Builder einrichten. Der Builder verknüpft viele der Elemente, die wir bereits definiert haben, um zu bestimmen, wie ein Build ausgeführt wird.

Fügen Sie die folgende Konfiguration am Ende der Datei ein:

/home/buildbot/master/master.cfg

. . .

# Builders
c['builders'] = []
c['builders'].append(
       util.BuilderConfig(name="npm",
               workernames=["npm-docker-worker"],
               factory=npm_f))

Wir hängen ein »util.BuilderConfig« -Objekt an die »builders« -Liste an. Denken Sie daran, dass unsere Build-Factory "+ npm_f " heißt, dass unser Docker-Worker " npm-docker-worker " heißt und dass der von uns definierte Scheduler Aufgaben an einen Worker mit dem Namen " npm +" übergibt. Unser Builder definiert die Beziehung zwischen diesen Elementen, sodass Änderungen in unserem Scheduler dazu führen, dass die Build-Factory-Schritte im Docker-Worker ausgeführt werden.

Konfigurieren Sie die Datenbank und das Webinterface

Schließlich können wir die Einstellungen für die Datenbank und die Weboberfläche konfigurieren. Im Gegensatz zu vielen der vorherigen Elemente werden diese beiden Einstellungen als Wörterbücher und nicht als Listen definiert. Das + db + Wörterbuch zeigt nur auf die + state.sqlite + Datei, die sich bereits in unserem + / home / buildbot / master + Verzeichnis befindet. Das "+ www +" - Wörterbuch enthält eine erhebliche Menge an zusätzlicher Konfiguration.

Fügen Sie Folgendes am Ende Ihrer Datei ein. Ersetzen Sie die Authentifizierungsinformationen, die Sie aus Ihrer ursprünglichen Buildbot-Masterkonfiguration kopiert haben, durch den folgenden Authentifizierungsblock:

/home/buildbot/master/master.cfg

. . .

# Database
c['db'] = { 'db_url': "sqlite:///state.sqlite",}

# Web Interface
c['www'] = dict(port=8010, plugins=dict(waterfall_view={}, console_view={}))













# GitHub webhook receiver
c['www']['change_hook_dialects'] = {
       'github': {
               'secret': '',
               'strict': True,
       }
}

Nach dem Definieren der Datenbankeinstellungen erstellen wir ein "+ www +" - Wörterbuch, das zunächst den zu überwachenden Port und einige der Ansichten definiert, die in die Webbenutzeroberfläche aufgenommen werden sollen. Als Nächstes fügen wir die Authentifizierungsanforderungen hinzu, die wir aus der vorherigen Buildbot-Konfigurationsdatei abgerufen haben.

Am Ende definieren wir ein Wörterbuch mit dem Namen "+ change_hook_dialects " innerhalb des " www " - Wörterbuchs. Wir verwenden dies, um einen GitHub-Änderungs-Hook zu definieren, der auf Webhook-Nachrichten von GitHub wartet. Wählen Sie eine sichere Passphrase für Ihr " secret +", mit der GitHub die gesendeten Nachrichten authentifiziert.

Wenn Sie fertig sind, speichern und schließen Sie die Datei.

Starten Sie den Buildbot-Master neu, um die neue Konfiguration anzuwenden

Zu diesem Zeitpunkt haben wir den Buildbot-Masterprozess vollständig neu konfiguriert. Wir müssen den Buildbot-Master-Prozess neu starten, um die Änderungen zu implementieren.

Bevor wir das tun, ist es wichtig, Ihre Datei auf Syntaxfehler zu überprüfen. Da wir die Konfiguration von Grund auf neu erstellt haben, ist die Wahrscheinlichkeit groß, dass wir einige Fehler gemacht haben.

Überprüfen Sie die Syntax der Datei, indem Sie Folgendes eingeben:

sudo buildbot checkconfig /home/buildbot/master

Der Befehl meldet alle gefundenen Probleme. Wenn keine Fehler gefunden wurden, erhalten Sie eine Meldung, die folgendermaßen aussieht:

OutputConfig file is good!

Wenn Fehler gemeldet werden, versuchen Sie, durch sorgfältiges Lesen der Fehlermeldung ein besseres Gefühl für die Fehlerursache zu bekommen. Öffnen Sie die Konfigurationsdatei erneut, um Probleme zu beheben.

Wenn keine Fehler mehr vorliegen, starten Sie den Buildbot-Master-Dienst neu, indem Sie Folgendes eingeben:

sudo systemctl restart buildbot-master

Überprüfen Sie, ob der Vorgang erfolgreich war, indem Sie Folgendes eingeben:

sudo systemctl status buildbot-master
Output● buildbot-master.service - BuildBot master service
  Loaded: loaded (/etc/systemd/system/buildbot-master.service; enabled; vendor preset: enabled)
   since Tue 2017-06-27 19:24:07 UTC; 2s ago
Main PID: 8298 (buildbot)
   Tasks: 2
  Memory: 51.7M
     CPU: 1.782s
  CGroup: /system.slice/buildbot-master.service
          └─8298 /usr/bin/python /usr/local/bin/buildbot start --nodaemon

Jun 27 19:24:07 bb5 systemd[1]: Started BuildBot master service

Konnte der Dienst erfolgreich neu gestartet werden, wird er als aktiv markiert.

Erstellen Sie einen GitHub-Webhook im Beispiel-Repository

Da Buildbot nun mit einem Web-Endpunkt konfiguriert ist, der GitHub-Webhook-Posts akzeptiert, können wir einen Webhook für unseren Fork konfigurieren.

Navigieren Sie in Ihrem Webbrowser zu Ihrem Zweig des Beispielprojekt-Repositorys:

https://github.com//hello_hapi

Klicken Sie auf die Registerkarte * Einstellungen *, um die Projekteinstellungen anzuzeigen. Klicken Sie im linken Menü der Einstellungsseite auf * Webhooks * (GitHub fordert Sie möglicherweise auf, Ihr Passwort während dieses Vorgangs erneut einzugeben, um Ihre Identität zu bestätigen):

image: https://assets.digitalocean.com/articles/buildbot_usage_1604/webhooks_initial_page.png [GitHub Webhooks-Startseite]

Klicken Sie rechts auf die Schaltfläche * Webhook hinzufügen *, um einen neuen Webhook hinzuzufügen.

Die folgende Seite enthält ein Formular zum Definieren Ihres Webhooks. Fügen Sie im Feld "* Payload URL *" die URL für den GitHub-Change-Hook-Endpunkt Ihres Projekts hinzu. Dies erfolgt durch Angabe des Protokolls "+ https: // ", gefolgt vom Domainnamen Ihres Buildbot-Masters, gefolgt von " / change_hook / github +".

Belassen Sie den Inhaltstyp auf "+ application / x-www-form-urlencoded +". Geben Sie im Feld * Secret * die geheime Passphrase ein, die Sie in Ihrer Buildbot-Masterkonfigurationsdatei ausgewählt haben. Sie können den Auslöser "Nur das Push-Ereignis" aktiviert lassen und das Kontrollkästchen "Aktiv" aktivieren:

image: https://assets.digitalocean.com/articles/buildbot_usage_1604/webhooks_form.png [GitHub-Webhooks-Formular]

Wenn Sie fertig sind, klicken Sie auf die Schaltfläche * Webhook hinzufügen *.

Sie kehren zum Webhook-Index des Projekts zurück, in dem Ihr neuer Webhook angezeigt wird. Wenn Sie einige Male aktualisieren, sollte ein grünes Häkchensymbol neben Ihrem Webhook angezeigt werden, um anzuzeigen, dass eine Nachricht erfolgreich übertragen wurde:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/webhooks_success_icon.png [GitHub Webhook Erfolgssymbol]

Wenn Sie stattdessen ein rotes X sehen, klicken Sie erneut auf den Webhook und scrollen Sie dann nach unten zum Abschnitt "Letzte Lieferungen". Weitere Informationen zu den Fehlern erhalten Sie, wenn Sie auf die fehlgeschlagene Zustellung klicken.

Testen des Webhooks

Nachdem wir unseren Webhook eingerichtet haben, können wir testen, ob Buildbot bei Änderungen an unserem Repository benachrichtigt wird, einen Build in Docker auslöst und die Testsuite erfolgreich ausführen kann.

Klicken Sie auf der Hauptseite Ihres GitHub-Fork auf die Schaltfläche * Neue Datei erstellen * links neben der grünen Schaltfläche "Klonen oder Herunterladen":

image: https://assets.digitalocean.com/articles/buildbot_usage_1604/create_new_file_button.png [GitHub-Schaltfläche zum Erstellen einer neuen Datei]

Erstellen Sie auf dem folgenden Bildschirm ein + dummy_file + und geben Sie einen Text ein:

image: https://assets.digitalocean.com/articles/buildbot_usage_1604/create_dummy_file.png [GitHub-Dummy-Datei erstellen]

Klicken Sie auf die Schaltfläche * Neue Datei übernehmen * am unteren Rand der Seite, wenn Sie fertig sind.

Besuchen Sie anschließend Ihre Buildbot-Weboberfläche und melden Sie sich an, wenn Sie noch nicht authentifiziert sind.

Abhängig davon, wie lange es her ist, dass Sie die Dummy-Datei in Ihr Repository geschrieben haben, wird möglicherweise ein Build in Bearbeitung angezeigt, der wie folgt aussieht:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/in_progress_build.png [Buildbot wird erstellt]

Wenn der Build bereits abgeschlossen ist, wird er stattdessen im Abschnitt "Aktuelle Builds" angezeigt:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/build_complete.png [Buildbot fertiggestellt]

Der Name des Builders, den wir definiert haben, "npm", wird zur Bezeichnung des Builds verwendet. Im Beispiel sehen wir auch eine ältere Ausführung des Sample Builders aus der vorherigen Master-Konfiguration.

Unabhängig vom Fortschritt klicken Sie auf den Buildernamen und die Buildnummer, um die Seite mit den Builddetails aufzurufen. Diese Ansicht enthält Informationen zum durchgeführten Build. Jeder Schritt, den wir der Build-Factory hinzugefügt haben, wird in einem eigenen Abschnitt angezeigt:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/build_details_view.png [Buildbot-Build-Detailansicht]

Wenn Sie auf einen Schritt klicken, wird die Ausgabe des Befehls angezeigt. Dies kann beim Debuggen helfen, wenn etwas schief geht:

image: https://assets.digitalocean.com/articles/buildbot_usage_1604/build_step_output.png [Buildbot-Buildschritt-Ausgabe]

In der obigen Ausgabe können wir überprüfen, ob Buildbot die drei Tests in unserer Testsuite erfolgreich ausgeführt hat.

Wenn der Build nicht erfolgreich abgeschlossen wurde, können Sie auch die anderen Registerkarten auf der Build-Detailseite sowie die Datei "+ / home / buildbot / master / twistd.log +" überprüfen.

Anpassen der Buildbot-Dienste

Bevor wir fertig sind, sollten wir einige Anpassungen an unseren Buildbot-Diensten vornehmen.

Derzeit haben wir einen Buildbot-Worker-Service für einen Worker definiert, den wir nicht mehr verwenden (unser Docker-Worker wird bei Bedarf automatisch gestartet). Wir sollten anhalten und unseren alten Arbeiter deaktivieren.

Geben Sie Folgendes ein, um den ausgeführten Dienst zu beenden und den Start beim Start zu deaktivieren:

sudo systemctl stop buildbot-worker
sudo systemctl disable buildbot-worker
OutputRemoved symlink /etc/systemd/system/buildbot-master.service.wants/buildbot-worker.service.

Die obige Ausgabe zeigt an, dass der Worker beim nächsten Start nicht gestartet wird. Geben Sie Folgendes ein, um zu überprüfen, ob der Dienst nicht mehr ausgeführt wird:

sudo systemctl status buildbot-worker
Output● buildbot-worker.service - BuildBot worker service
  Loaded: loaded (/etc/systemd/system/buildbot-worker.service; disabled; vendor preset: enabled)


Jun 27 21:12:48 bb6 systemd[1]: Started BuildBot worker service.
Jun 27 21:55:51 bb6 systemd[1]: Stopping BuildBot worker service...
Jun 27 21:55:51 bb6 systemd[1]: Stopped BuildBot worker service.

Als letztes sollten wir eine weiche Abhängigkeit zwischen unserem Buildbot-Master-Service und dem Docker-Daemon herstellen. Da der Buildbot-Master-Service keine neuen Mitarbeiter ohne Docker bereitstellen kann, sollten wir diese Anforderung definieren.

Öffnen Sie die Datei "+ buildbot-master.service " im Verzeichnis " / etc / systemd / system +", um die Servicedatei anzupassen:

sudo nano /etc/systemd/system/buildbot-master.service

Fügen Sie im Abschnitt "+ [Unit] " der Direktive " After" nach dem Eintrag "+ network.target" "+ docker.service" hinzu. Fügen Sie eine zusätzliche "+ Wants A" -Direktive hinzu, die auch "+ docker.service" nennt. Das "+ Wants " stellt eine weiche Abhängigkeit her, während die Direktive " After +" die Startreihenfolge festlegt:

/etc/systemd/system/buildbot-master.service

[Unit]
Description=BuildBot master service
After=network.target


[Service]
User=buildbot
Group=buildbot
WorkingDirectory=/home/buildbot/master
ExecStart=/usr/local/bin/buildbot start --nodaemon

[Install]
WantedBy=multi-user.target

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Laden Sie den systemd-Daemon und den Dienst neu, um die Konfiguration sofort anzuwenden:

sudo systemctl daemon-reload
sudo systemctl restart buildbot-master

Der Buildbot-Master-Prozess sollte jetzt gestartet werden, nachdem Docker verfügbar ist.

Fazit

In diesem Tutorial haben wir Buildbot so konfiguriert, dass Änderungen an einem GitHub-Repository mithilfe von Webhooks abgehört werden. Wenn eine Änderung eingeht, startet Buildbot einen Container basierend auf einem benutzerdefinierten Docker-Image, um das neue Commit zu testen. Das Docker-Image enthält eine Buildbot-Worker-Instanz sowie die Abhängigkeiten, die zum Testen des Projektcodes erforderlich sind. Auf diese Weise kann Buildbot Buildbot-Worker bei Bedarf dynamisch starten, wenn Änderungen am Repository vorgenommen werden.

Related