Beispiel für die Implementierung einer kontinuierlichen Integration mit BuildBot

(Bild von Computerizer von Pixabay)

Hallo!

Mein Name ist Evgeny Cherkin , ich bin Programmierer im Entwicklungsteam von Polymetal .

Wenn Sie ein Großprojekt starten, denken Sie: „Welche Software ist für die Wartung besser geeignet?“. Ein IT-Projekt vor der Veröffentlichung der nächsten Version durchläuft eine Reihe von Phasen. Es ist gut, wenn die Kette dieser Schritte automatisiert ist. Der automatisierte Prozess zum Freigeben einer neuen Version eines IT-Projekts wird als kontinuierliche Integration bezeichnet . BuildBot hat sich als guter Helfer für uns erwiesen und diesen Prozess implementiert.

In diesem Artikel habe ich beschlossen, einen Überblick über die Funktionen von BuildBot zu geben . Was kann diese Software? Wie kann man sich ihm nähern und wie kann man mit ihm eine normale EFFEKTIVE ARBEITSBEZIEHUNG aufbauen? Sie können unsere Erfahrung auch auf sich selbst anwenden, indem Sie auf Ihrer Maschine einen funktionierenden Service zum Zusammenstellen und Testen Ihres Projekts erstellen.

1. Warum ist BuildBot?

---

Früher bei habr-e bin ich auf Artikel zur Implementierung der kontinuierlichen Integration mit BuildBot gestoßen . Zum Beispiel schien mir dieser am informativsten. Es gibt noch ein anderes Beispiel - einfacher . Diese Artikel können mit einem Beispiel aus dem Handbuch gewürzt werden, und das ist danach in englischer Sprache. Das Coupé ist ein guter Ausgangspunkt. Nachdem Sie diese Artikel gelesen haben, möchten Sie wahrscheinlich sofort etwas auf BuildBot tun.

Hör auf! Hat es jemand in seinen Projekten verwendet? Es stellt sich heraus, ja, viele haben es in ihren Aufgaben angewendet. Beispiele für die Verwendung von BuildBot finden Sie in den Google- Codearchiven .

Was ist die Logik von Leuten, die Buildbot verwenden ? Immerhin gibt es noch andere Tools: CruiseControl und Jenkins . Ich werde so antworten. Für die meisten Aufgaben wird Jenkins wirklich ausreichen. BuildBot wiederum ist anpassungsfähiger und die dortigen Aufgaben lassen sich genauso einfach lösen wie in Jenkins . Wähle dich. Da wir jedoch nach einem Tool für ein sich entwickelndes Zielprojekt suchen, wählen Sie das Tool, mit dem wir ausgehend von einfachen Schritten ein Build-System mit Interaktivität und einer einzigartigen Benutzeroberfläche erstellen können.

Für diejenigen, deren Zielprojekt in Python geschrieben ist, stellt sich die Frage: „Warum nicht ein Integrationssystem wählen, das eine klare Schnittstelle in Bezug auf die im Projekt verwendete Sprache hat?“. Und dann ist es Zeit, die Vorteile von BuildBot vorzustellen .

Also unser „Instrumentalquartett“. Für mich selbst habe ich die vier Funktionen von BuildBot definiert :

1. Dies ist ein Open Source Framework unter der GPL
2. Hierbei wird Python als Konfigurationstool verwendet und die erforderlichen Aktionen beschrieben.
3. Dies ist eine Gelegenheit, eine Antwort von der Maschine zu erhalten, auf der die Montage stattfindet.
4. Dies sind schließlich die Mindestanforderungen für den Host. Die Bereitstellung erfordert Python und Twisted, und es ist keine virtuelle Maschine oder Java-Maschine erforderlich.

2. Konzept unter der Leitung von BuildMaster

---

Im Zentrum der Aufgabenverteilungsarchitektur steht BuildMaster . Es ist ein Dienst, der:

• Verfolgt Änderungen im Projektquellbaum
• Sendet die Befehle, die der Worker-Dienst ausführen soll, um ein Projekt zu erstellen und zu testen
• benachrichtigt Benutzer über die Ergebnisse der ergriffenen Maßnahmen

BuildMaster wird über die Datei master.cfg konfiguriert. Diese Datei befindet sich im Stammverzeichnis von BuildMaster . Später werde ich zeigen, wie diese Wurzel erstellt wird. Die Datei master.cfg selbst enthält Python, ein Skript, das BuildBot- Aufrufe verwendet.

Der nächstwichtigste BuildBot heißt Worker . Dieser Dienst kann auf einem anderen Host mit einem anderen Betriebssystem oder möglicherweise auf BuildMaster ausgeführt werden . Es kann auch in einer speziell vorbereiteten virtuellen Umgebung mit eigenen Paketen und Variablen vorhanden sein. Diese virtuellen Umgebungen können mit Python-Dienstprogrammen wie vertualenv, venv vorbereitet werden.

BuildMaster sendet Befehle an jeden Worker , der sie wiederum ausführt. Das heißt, es stellt sich heraus, dass der Prozess des Erstellens und Testens des Projekts unter Windows auf den Worker und unter Linux auf einen anderen Worker übertragen werden kann.

Das Auschecken des Projektquellcodes erfolgt bei jedem Worker .

3. Installation

---

Also lass uns gehen. Ich werde Ubuntu 18.04 als Host verwenden. Darauf werde ich einen BuildMaster -a und einen Worker -a platzieren. Aber zuerst müssen Sie python3.7 installieren:

sudo apt-get update sudo apt-get install python3.7 

Für diejenigen, die python3.7.2 anstelle von 3.7.1 benötigen, können Sie Folgendes tun:

 sudo apt-get update sudo apt-get software-properties-common sudo add-apt-repository ppa:deadsnakes/ppa sudo apt-get install python3.7 sudo ln -fs /usr/bin/python3.7 /usr/bin/python3 pip3 install --upgrade pip 

Der nächste Schritt ist die Installation von Twited und BuildBot sowie von Paketen, die zusätzliche BuildBot -a-Funktionen ermöglichen.

 /*   sudo        /usr/local/lib/python3.7/dist-packages*/ #     Worker- sudo pip install twisted # twisted sudo pip install buildbot #BuildMaster #  pip install pysqlite3 #  sqllite    pip install jinja2 #framework  django,  web     pip install autobahn #Web c   BuildMaster->Worker pip install sqlalchemy sqlalchemy-migrate #     # Web  BuildBot-a pip install buildbot-www buildbot-grid-view buildbot-console-view buildbot-waterfall-view pip install python-dateutil #   web #         pip install buildbot-worker #Worker #  sudo pip install virtualenv #  

4. Erste Schritte

---

Zeit, einen BuildMaster zu erstellen. Wir werden es im Ordner / home / habr / master haben .

 mkdir master buildbot create-master master #     

Der nächste Schritt. Erstellen Sie einen Worker . Wir werden es im Ordner / home / habr / worker haben .

 mkdir worker buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password 

Wenn Sie Worker starten, wird standardmäßig ein Ordner in / home / habr / worker mit dem Namen des Projekts erstellt, der in master.cfg angegeben ist . In dem Ordner mit dem Namen des Projekts erstellt er das Erstellungsverzeichnis, und dann wird das Auschecken darin durchgeführt. Das Arbeitsverzeichnis für Worker ist das Verzeichnis / home / habr / yourProject / build .

Goldener Schlüssel
Und nun zu dem, was ich im vorherigen Absatz geschrieben habe: Das Skript, das Worker vom Master remote in diesem Verzeichnis ausführen muss, wird nicht ausgeführt, da das Skript keine Berechtigung zum Ausführen hat. Um die Situation zu beheben, benötigen Sie einen Schlüssel --umask = 0o22 , wodurch das Schreiben in dieses Verzeichnis verboten wird , jedoch Startrechte verbleiben . Und das brauchen wir nur.

BuildMaster und Worker stellen eine Verbindung zwischen ihnen her. Es kommt vor, dass es abbricht und Worker einige Zeit auf eine Antwort von BuildMaster wartet. Wenn keine Antwort empfangen wird, wird die Verbindung neu gestartet. Der Schlüssel --keepalive = 60 ist genau das, was Sie benötigen, um die Zeit anzugeben, nach der die Verbindung neu gestartet wird.

5. Konfiguration. Schritt für Schritt Rezept

---

Die BuildMaster- Konfiguration erfolgt auf der Maschinenseite, wo wir den Befehl create-master ausgeführt haben. In unserem Fall ist dies das Verzeichnis / home / habr / master . Die Konfigurationsdatei master.cfg ist noch nicht vorhanden, aber der Befehl selbst hat die Datei master.cmg.sample bereits erstellt. Sie müssen es in master.cfg.sample in master.cfg umbenennen

 mv master.cfg.sample master.cfg 

Öffnen wir diese master.cfg . Und wir werden analysieren, woraus es besteht. Danach versuchen wir, eine eigene Konfigurationsdatei zu erstellen.

5.1 BuildmasterConfig

 c = BuildmasterConfig = {} 

BuildmasterConfig - das Basiswörterbuch der Konfigurationsdatei. Es muss in der Konfigurationsdatei enthalten sein. Zur Vereinfachung der Verwendung wird der Alias "c" in den Konfigurationscode eingegeben. Schlüsselnamen in c ["keyFromDist"] sind feste Elemente für die Interaktion mit BuildMaster . Unter jedem Schlüssel wird das entsprechende Objekt als Wert ersetzt.

5.2 Arbeiter

 c['workers'] = [worker.Worker("example-worker", "pass")] 

Dieses Mal weisen wir auf die BuildMaster- Liste der Worker hin . Wir haben Worker oben erstellt, indem wir Ihren Worker -Namen und Ihr Passwort angegeben haben . Jetzt müssen sie anstelle von Beispielarbeiter angegeben und übergeben werden .

5.3 change_source

 c['change_source'] = [] c['change_source'].append(changes.GitPoller( 'git://github.com/buildbot/hello-world.git', workdir='gitpoller-workdir', branch='master', pollInterval=300)) 

Mit dem Schlüssel change_source des c- Wörterbuchs erhalten wir Zugriff auf die Liste, in der Sie das Objekt ablegen möchten, das das Repository mit dem Projektquellcode abfragt . In diesem Beispiel wird das Git-Repository verwendet, das in bestimmten Abständen abgefragt wird.

Das erste Argument ist der Pfad zu Ihrem Repository.

workdir ist der Pfad zu dem Ordner, in dem auf der Arbeiterseite relativ zum Pfad / home / habr / worker / yourProject / build die lokale Version des Repositorys gespeichert wird.

Der Zweig enthält einen bestimmten Zweig im Repository, der überwacht werden soll.

pollInterval enthält die Anzahl der Sekunden, nach denen BuildMaster das Repository nach Änderungen abfragt .

Es gibt verschiedene Methoden, um Änderungen in einem Projekt-Repository zu verfolgen.

Die einfachste Methode ist Polling . Dies bedeutet, dass BuildMaster den Server regelmäßig mit dem Repository abfragt . Wenn das Festschreiben die Änderungen im Repository widerspiegelt, erstellt BuildMaster mit einiger Verzögerung ein internes Änderungsobjekt und sendet es an den Scheduler- Ereignishandler, der die Schritte zum Erstellen und Testen des Projekts in Worker startet. Unter diesen Schritten wird die Aktualisierung des Repositorys angezeigt. Auf Worker wird eine lokale Kopie des Repositorys erstellt. Details dieses Prozesses werden nachstehend in den nächsten beiden Abschnitten ( 5.4 und 5.5 ) offenbart.

Eine noch elegantere Methode zum Verfolgen von Änderungen im Repository besteht darin, Nachrichten direkt von dem Server, auf dem es sich befindet, an BuildMaster zu senden, um die Quellcodes des Projekts zu ändern . In diesem Fall sendet der Server mit dem Projekt-Repository eine Nachricht an BuildMaster , sobald der Entwickler eine Festschreibung vornimmt . Und das wird wiederum durch das Erstellen eines PBChangeSource- Objekts abgefangen. Außerdem wird dieses Objekt an den Scheduler übertragen , der die Schritte für die Montage des Projekts und dessen Test aktiviert. Ein wichtiger Teil dieser Methode ist die Arbeit mit Server- Hook- Skripten im Repository. In dem Hook- Skript, das für die Verarbeitung von Aktionen während des Festschreibens verantwortlich ist, müssen Sie das Dienstprogramm sendchange aufrufen und die Netzwerkadresse von BuildMaster angeben . Sie müssen den Netzwerkport angeben, der PBChangeSource abhört . PBChangeSource ist übrigens Teil von BuildMaster . Diese Methode erfordert die Berechtigung admin -a auf dem Server, auf dem sich das Projektrepository befindet. Zuerst müssen Sie ein Backup-Repository erstellen.

5.4 Schuppen

 c['schedulers'] = [] c['schedulers'].append(schedulers.SingleBranchScheduler( name="all", change_filter=util.ChangeFilter(branch='master'), treeStableTimer=None, builderNames=["runtests"])) c['schedulers'].append(schedulers.ForceScheduler( name="force", builderNames=["runtests"])) 

Scheduler ist ein Element, das als Auslöser fungiert und die gesamte Montage- und Testkette eines Projekts ausführt.


Die von change_source aufgezeichneten Änderungen wurden während des Vorgangs von BuildBot -a in das Change- Objekt konvertiert, und jetzt erstellt jeder darauf basierende Sheduler Anforderungen zum Starten des Projekterstellungsprozesses. Es wird jedoch auch festgelegt, wann diese Anforderungen an die Warteschlange gesendet werden sollen. Objekt Builder führt eine Anforderungswarteschlange und überwacht den Status der aktuellen Assembly auf einem separaten Worker -e. Builder ist sowohl für BuildMaster -e als auch für Worker -e vorhanden. Er sendet einen bestimmten Build von BuildMaster an Worker , eine Reihe von Schritten, die befolgt werden müssen.
Wir sehen, dass im aktuellen Beispiel solcher Scheduler 2 Teile erstellt werden. Darüber hinaus hat jeder seinen eigenen Typ.

SingleBranchScheduler ist eine der beliebtesten Zeitplanklassen. Es überwacht einen Zweig und wird durch eine aufgezeichnete Änderung in ihm ausgelöst. Wenn er die Änderungen sieht, kann er das Senden einer Konstruktionsanforderung verschieben (auf den im speziellen Parameter treeStableTimer angegebenen Zeitraum verschieben ). Der Name gibt den Namen des Zeitplans an, der in der BuildBot- Webschnittstelle angezeigt wird. In ChangeFilter wird ein Filter festgelegt, nachdem Änderungen in der Verzweigung den Zeitplan zum Senden einer Erstellungsanforderung auffordern . Der Name Builder -a wird in builderNames angegeben , die wir etwas später angeben werden. Der Name in unserem Fall entspricht dem Namen des Projekts: yourProject .

ForceScheduler ist eine sehr einfache Sache. Diese Art von Zeitplan wird durch einen Mausklick über die BuildBot- Web-Oberfläche ausgelöst. Parameter haben die gleiche Essenz wie in SingleBranchScheduler .

PS Nr. 3. Plötzlich nützlich sein
Periodisch ist ein Zeitplan, der mit einer bestimmten zeitlich festgelegten Frequenz ausgelöst wird. Es sieht aus wie ein Anruf wie dieser

 from buildbot.plugins import schedulers nightly = schedulers.Periodic(name="daily", builderNames=["full-solaris"], periodicBuildTimer=24*60*60) c['schedulers'] = [nightly] 

5.5 BuildFactory

 factory = util.BuildFactory() factory.addStep(steps.Git(repourl='git://github.com/buildbot/hello-world.git', mode='incremental')) factory.addStep(steps.ShellCommand(command=["trial", "hello"], env={"PYTHONPATH": "."})) 

periodicBuildTimer legt die Zeit dieser Periodizität in Sekunden fest.

BuildFactory erstellt einen konkreten Build , den der Builder dann an den Worker sendet. BuildFactory gibt die Schritte an, die ein Worker ausführen sollte. Schritte werden durch Aufrufen der addStep- Methode hinzugefügt .


Der erste in diesem Beispiel hinzugefügte Schritt ist git clean -d -f -f –x und dann git checkout . Diese Aktionen sind in den Methodenparameter eingebettet, der nicht eindeutig angegeben ist, aber den Standardwert von fresh impliziert. Der Parameter mode = 'incremental' gibt an, dass die Dateien aus dem Verzeichnis, in dem das Cheechout durchgeführt wird, zwar im Repository fehlen, aber unberührt bleiben.

Der zweite hinzugefügte Schritt besteht darin, das Testskript mit dem Parameter " Hallo" auf der Arbeiterseite aus dem Verzeichnis / home / habr / worker / yourProject / build mit der Umgebungsvariablen PATHONPATH = ... aufzurufen. Sie können also Ihre eigenen Skripte schreiben und sie auf der Arbeiterseite -a ausführen durch den Schritt util.ShellCommand . Diese Skripte können direkt in das Repository gestellt werden. Während des Cheechouts gehen sie dann zu / home / habr / worker / yourProject / build . Dann gibt es jedoch zwei „Aber“:

1. Worker muss mit dem Schalter --umask erstellt werden, damit die Ausführungsrechte nach dem Auschecken -a nicht blockiert werden.
2. Wenn git diese Skripte pusht , muss die exacutable Eigenschaft angegeben werden, damit Git mit chechout -e nicht das Recht verliert, das Skript auszuführen.

5.6 Bauherren

 c['builders'] = [] c['builders'].append(util.BuilderConfig(name="runtests", workernames=["example-worker"], factory=factory)) 

Über was Builder hier beschrieben wurde . Jetzt werde ich ausführlicher darüber sprechen, wie es erstellt wird. BuilderConfig ist ein Konstruktor- Builder . Sie können in c ['Builder'] mehrere solcher Konstruktoren angeben, da dies eine Liste von Objekten vom Typ Builder ist . Jetzt werden wir das Beispiel aus BuildBot leicht umschreiben, um es unserer Aufgabe näher zu bringen.

 c['builders'] = [] c['builders'].append(util.BuilderConfig(name="yourProject", workernames=["yourWorkerName"], factory=factory)) 

Jetzt werde ich über die Parameter BuilderConfig erzählen.

name legt den Namensgenerator -a fest. Hier haben wir es yourProject genannt . Dies bedeutet, dass auf dem Worker genau dieser Pfad / home / habr / worker / yourProject / build erstellt wird. Sheduler sucht nach einem Builder mit diesem Namen.

Arbeitsnamen enthält eine Liste der Arbeiter . Jedes davon muss zu c ['Arbeiter'] hinzugefügt werden.

Factory ist der spezifische Build, dem der Builder zugeordnet ist . Es wird ein Build- Objekt an Worker gesendet , um alle Schritte auszuführen, aus denen dieser Build -a besteht.

6. Beispiel einer eigenen Konfiguration

---

Hier ist die Architektur eines Beispielprojekts, das ich über BuildBot implementieren möchte
.

Wir werden svn als Versionskontrollsystem verwenden. Das Repository selbst befindet sich in einer bestimmten Cloud. Hier ist die Adresse dieser Cloud svn.host/svn/yourProject/trunk . In der Cloud unter svn gibt es einen Benutzernamen: user , passwd: password account. Die Skripte, die die Schritte build -a darstellen, befinden sich auch im Zweig svn in einem separaten Ordner buildbot / worker_linux . Diese Skripte befinden sich im Repository, wobei die ausführbare Eigenschaft gespeichert ist.

BuildMaster und Worker arbeiten auf demselben project.host- Host. BuildMaster speichert seine Dateien im Ordner / home / habr / master . Worker speichert den folgenden Pfad / home / habr / worker . Die Kommunikation zwischen den BuildMaster- und Worker- Prozessen erfolgt über den 4000-Port unter Verwendung des BuildBot- a-Protokolls, dh des 'pb'- Protokolls.

Das Zielprojekt ist vollständig in Python geschrieben. Die Aufgabe besteht darin, die Änderungen zu verfolgen, eine ausführbare Datei zu erstellen, Dokumentation zu erstellen und Tests durchzuführen. Im Fehlerfall müssen alle Entwickler eine Nachricht an die E-Mail senden, dass eine Aktion fehlgeschlagen ist.

Wir werden das BuildBot- Web-Mapping mit Port 80 für project.host verbinden . Apatch ist optional. Die verdrehte Bibliothek hat bereits einen Webserver, BuildBot verwendet ihn.

Wir werden SQLite verwenden, um interne Informationen für BuildBot zu speichern.

Zum Versenden benötigen Sie den Host smtp.your.domain - er ermöglicht das Senden von E-Mails von projectHost@your.domain ohne Authentifizierung. Auch auf dem Host ' smtp ' wird das Protokoll um 1025 abgehört.

An dem Prozess sind zwei Personen beteiligt: Administrator und Benutzer . admin verwaltet BuildBot . Benutzer ist die Person, die das Commit festlegt .

Eine austauschbare Datei wird über pyinstaller generiert. Die Dokumentation wird durch Sauerstoff erzeugt.

Für diese Architektur habe ich diese master.cfg geschrieben :


Zuerst müssen Sie BuildMaster und Worker -a erstellen . Fügen Sie dann diese Datei master.cfg in / home / habr / master ein .

Der nächste Schritt ist das Starten des BuildMaster- Dienstes

 sudo buildbot start /home/habr/master 

Starten Sie dann den Worker -a-Dienst

 buildbot-worker start /home/habr/worker 

Fertig! Jetzt verfolgt Buildbot die Änderungen und führt sie beim Festschreiben in svn aus. Dabei werden die Schritte zum Erstellen und Testen des Projekts mit der oben genannten Architektur ausgeführt.

Im Folgenden werde ich einige Funktionen der obigen master.cfg beschreiben.

6.1 Auf dem Weg zu Ihrem master.cfg

Beim Schreiben Ihrer master.cfg werden viele Fehler gemacht, sodass Sie die Protokolldatei lesen müssen. Es wird sowohl auf dem absoluten BuildMaster -ec-Pfad /home/habr/master/twistd.log als auch auf der Worker- Seite mit dem absoluten Pfad /home/habr/worker/twistd.log gespeichert . Wenn Sie den Fehler lesen und beheben, müssen Sie den BuildMaster -a-Dienst neu starten . So geht's:

 sudo buildbot stop /home/habr/master sudo buildbot upgrade-master /home/habr/master sudo buildbot start /home/habr/master 

6.2 Mit svn arbeiten

 svn_poller = changes.SVNPoller(repourl="https://svn.host/svn/yourProject/trunk", svnuser="user", svnpasswd="password", pollinterval=60, split_file=util.svn.split_file_alwaystrunk ) c['change_source'] = svn_poller hourlyscheduler = schedulers.SingleBranchScheduler( name="your-project-schedulers", change_filter=util.ChangeFilter(branch=None), builderNames=["yourProject"], properties = {'owner': 'admin'} ) c['schedulers'] = [hourlyscheduler] checkout = steps.SVN(repourl='https://svn.host/svn/yourProject/trunk', mode='full', method='fresh', username="user", password="password", haltOnFailure=True) 

Schauen Sie sich zunächst svn_poller an . Dies ist dieselbe Schnittstelle, die das Repository regelmäßig einmal pro Minute abfragt. In diesem Fall greift svn_poller nur auf den Trunk- Zweig zu. Der mysteriöse Parameter split_file = util.svn.split_file_alwaystrunk legt die Regeln fest: So teilen Sie die Struktur von SVN- Ordnern in Zweige auf. Er bietet ihnen relative Wege an. Split_file_alwaystrunk vereinfacht wiederum den Prozess, indem angegeben wird, dass sich nur Trunk im Repository befindet.

In Schedulern wird ChangeFilter angegeben , der None sieht und den Trunk- Zweig gemäß der angegebenen Zuordnung über split_file_alwaystrunk mit ihm verknüpft . Als Reaktion auf Änderungen im Trunk wird der Builder mit dem Namen yourProject gestartet .

Eigenschaften hier sind erforderlich, damit der Administrator den Newsletter von der Montage und den Testergebnissen als Eigentümer des Prozesses erhält.

Mit dem Schritt " Auschecken erstellen" können alle Dateien in der lokalen Version des Worker- Repositorys vollständig gelöscht werden. A Führen Sie dann das vollständige SVN-Update durch . Der Modus wird über den Parameter mode = full , method = fresh konfiguriert. Der Parameter haltOnTailure gibt an, dass bei nicht erfolgreichem svn-Update der gesamte Montage- und Testprozess angehalten werden sollte, da weitere Schritte keinen Sinn ergeben.

6.3 Ein Brief an Sie: Reporter sind berechtigt zu erklären

Reporter ist ein Mail-Benachrichtigungsdienst.

 template_html=u'''\ <h4>  : {{ summary }}</h4> <p>   : {{ workername }}</p> <p>: {{ projects }}</p> <p>         : {{ buildbot_url }}</p> <p>         : {{ build_url }}</p> <p> WinSCP     c ip:xxx.xx.xxx.xx.   habr/password,   executable    ~/worker/yourProject/build/dist.</p> <p><b>    Buildbot</b></p> ''' sendMessageToAll = reporters.MailNotifier(fromaddr="projectHost@your.domain", sendToInterestedUsers=True, lookup="your.domain", relayhost="smtp.your.domain", smtpPort=1025, mode="warnings", extraRecipients=['user@your.domain'], messageFormatter=reporters.MessageFormatter( template=template_html, template_type='html', wantProperties=True, wantSteps=True) ) c['services'] = [sendMessageToAll] 

Es kann Nachrichten auf viele Arten senden.

MailNotifier verwendet Mail, um Benachrichtigungen zu senden.

template_html legt die Textvorlage für den Newsletter fest. Verwenden Sie zum Erstellen von Markups HTML. Es wird von der jinja2- Engine modifiziert (kann mit django verglichen werden ). BuildBot verfügt über eine Reihe von Variablen, deren Werte beim Erstellen des Nachrichtentextes in die Vorlage eingesetzt werden. Diese Variablen sind in {{doppelte geschweifte Klammern}} eingeschrieben. So zeigt beispielsweise die Zusammenfassung den Status abgeschlossener Vorgänge an, d. H. Erfolg oder Misserfolg. Und Projekte geben yourProject aus . Mit Steuerbefehlen in jinja2 , BuildBot- Variablen und Python-String-Formatierern können Sie also eine sehr informative Nachricht erstellen.

MailNotifier enthält die folgenden Argumente.

fromaddr - die Adresse, von der jeder den Newsletter erhält.

sendToInterestedUsers = True sendet eine Nachricht an den Eigentümer und Benutzer, der das Commit durchgeführt hat .

Lookup - Suffix, das den Namen der Benutzer hinzugefügt wird, die den Newsletter erhalten. Der Administrator als Benutzer erhält den Newsletter unter admin@your.domain.

Relayhost gibt den Hostnamen an, auf dem der SMTP- Server geöffnet ist, und smptPort gibt die Portnummer an, die der SMTP- Server überwacht .

mode = "warning" besagt, dass das Mailing nur durchgeführt werden soll, wenn mindestens ein Build- Schritt mit einem Fehler- oder Warnstatus beendet wurde. Im Erfolgsfall ist kein Mailing erforderlich.

extraRecipients enthält neben dem Eigentümer und der Person, die das Commit durchgeführt hat, eine Liste der Personen, an die das Mailing erfolgen soll .

messageFormatter ist ein Objekt, das das Format der Nachricht, ihre Vorlage und die von jinja2 verfügbaren Variablen definiert . Parameter wie wantProperties = True und wantSteps = True geben diesen Satz verfügbarer Variablen an.

with ['services'] = [sendMessageToAll] bietet eine Liste von Diensten, darunter unsereReporter .

Wir haben es geschafft! Herzliche Glückwünsche

---

Wir haben unsere eigene Konfiguration erstellt und die Funktionalität von BuildBot erkannt . Ich denke, dies reicht aus, um zu verstehen, ob dieses Tool zum Erstellen Ihres Projekts benötigt wird. Ist er für dich interessant? Wird es für Sie nützlich sein? Ist es bequem, damit zu arbeiten? Dann schreibe ich diesen Artikel aus gutem Grund.

Und noch etwas.Ich möchte, dass die professionelle Community, die BuildBot verwendet , breiter wird, Handbücher übersetzt und weitere Beispiele.

Vielen Dank für Ihre Aufmerksamkeit. Viel Glück.