Ich musste den Prozess zum Zusammenstellen und Bereitstellen von Softwarepaketen aus dem Git-Repository für die Site einrichten. Und nachdem ich vor nicht allzu langer Zeit hier auf Habr den Artikel über Buildbot (den Link am Ende) gesehen hatte, beschloss ich, es zu versuchen und mich dafür zu bewerben.
Da Buildbot ein verteiltes System ist, ist es für jede Architektur und jedes Betriebssystem logisch, einen separaten Assemblyhost zu erstellen. In unserem Fall sind dies LXC-Container (im Fall von Linux) und Qemu (im Fall von Windows):
- vm-srv-build1 - centos 7, es wird einen buildbot master und einen der arbeiter geben
- vm-srv-build2 - Debian 10 zum Erstellen von DEB-Paketen
- vm-srv-build3 - Windows 10, für die Montage verstehen Sie selbst was
Wir werden Rac GUI sammeln - eine grafische Darstellung von 1C rac für die Verwaltung eines Serverclusters. Unter Linux werden Standardtools für jedes Betriebssystem verwendet. Freewrap wird verwendet, um eine exe-Datei für Windows aus einem tcl-Skript zu erstellen.
Installation
GNU / Linux
Für die Installation reicht die Dokumentation im Netzwerk 1 , 2 . Und es verursacht keine besonderen Probleme:
Für den Meister:
pip3 install buildbot pip3 install twisted pip3 install autobahn pip3 install pysqlite3 pip3 install sqlalchemy sqlalchemy-migrate pip3 install buildbot-www buildbot-grid-view buildbot-console-view buildbot-waterfall-view pip3 install python-dateutil
Für die "Arbeiter" ist dies ausreichend:
pip3 install buildbot-worker
Natürlich wäre es korrekter, Pakete für jedes Betriebssystem zu sammeln, aber dies ist nicht im Umfang des Artikels enthalten. Wir lassen auch die Beschreibung der Konfiguration von Containern für die Arbeit weg. Ich stelle nur fest, dass ich ProxMox VE verwende. Außerdem müssen Sie Pakete für jede Achse installieren, die für die Montage erforderlich ist (Centos: rpmdevtools usw .; debian: build-essential, dh-make, pbuilder usw.).
Die Projektassemblierungs- und Buildbot-Dienste werden im Auftrag eines nicht privilegierten Benutzers gestartet. Sie müssen sie daher auf allen am Prozess beteiligten Hosts erstellen:
adduser buildbot
Konfigurieren Sie als Nächstes den automatischen Start von Diensten auf jedem der Hosts (Container):
Systemd-Einheit zum Ausführen des Assistenten:
touch /etc/systemd/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 ExecReload=/bin/kill -HUP $MAINPID [Install] WantedBy=multi-user.target
und "Arbeiter"
touch /etc/systemd/buildbot-worker.service [Unit] Description=BuildBot worker service After=network.target [Service]master User=buildbot Group=buildbot WorkingDirectory=/home/buildbot/worker ExecStart=/usr/local/bin/buildbot-worker start --nodaemon [Install] WantedBy=buildbot-master.service
Da sich alle Skripte (in unserem Fall) in / usr / local / befinden, sollten Sie den Pfad zu ihnen in Umgebungsvariablen schreiben:
nano /root/.bash_profile PATH=$PATH:$HOME/.local/bin:$HOME/bin:/usr/local/bin
Danach können Sie eine Verzeichnisinfrastruktur für die "Worker" (auf allen Hosts) erstellen. Registrieren Sie sich dazu unter dem Buildbot-Benutzer und führen Sie die folgenden Befehle aus:
Auf dem ersten Host vm-srv-build1:
su - buildbot mkdir /home/buildbot/worker cd ~ buildbot-worker create-worker --umask=0o22 --keepalive=60 worker vm-srv-build1:4000 CentOS 123456
Auf dem zweiten Host, vm-srv-build2:
su - buildbot mkdir /home/buildbot/worker cd ~ buildbot-worker create-worker --umask=0o22 --keepalive=60 worker vm-srv-build1:4000 Debian-10 123456
Auf funktionierenden Hosts kann der Buildbot-Worker-Dienst gestartet werden
systemctl start buildbot-worker
MS Windows
Als "funktionierender" Build für Windows wird eine virtuelle Maschine mit der neuesten Win10-Version verwendet.
Um zu arbeiten, brauchen Sie:
Nachdem alle oben genannten Funktionen installiert wurden, können Sie den Buildbot selbst installieren:
pip install buildbot-worker
Erstellen Sie ein Arbeitsverzeichnis
md c:\worker
Und renn
buildbot-worker start c:\worker
Wenn alles funktioniert (siehe das Protokoll c: \ Worker \ Twistd.log), können Sie unseren "Worker" als Dienst registrieren, indem Sie der Registrierung ein Element mit dem Arbeitsverzeichnis hinzufügen (Befehle werden in Powershell ausgeführt, das als Administrator ausgeführt wird):
buildbot_worker_windows_service.exe --user VM-SRV-BUILD3\buildbot --password 123456 --startup auto install New-ItemProperty -path Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BuildBot\Parameters -Name directories -PropertyType String -Value c:\worker
Und du kannst einen Diener führen
Start-Service buildbot
Das ist alles mit den "Arbeitern", dann müssen Sie sie nicht mehr berühren, das gesamte Management geht vom Meister.
Setup-Assistent
Zunächst erstellen wir die Infrastruktur für den Assistenten (auf dem Haupthost). Dazu registrieren wir uns unter dem Buildbot-Benutzer und führen die folgenden Befehle aus:
su - buildbot mkdir /home/buildbot/master cd ~ buildbot create-master master
Erstellen Sie für fertige Pakete das Builds-Verzeichnis
mkdir /home/buildbot/builds
Die Datei master.cfg wurde im Verzeichnis / home / buildbot / master / erstellt. Diese Datei ist ein Python-Code und enthält eine Beschreibung aller Mechanismen des Systems. Wir werden weiterhin damit arbeiten.
nano /home/buildbot/master/master.cfg
import os, re from buildbot.plugins import steps, util, schedulers, worker, changes, reporters c= BuildmasterConfig ={}
Um die Zusammenstellung von Paketen verschiedener Versionen zu automatisieren, damit Sie nicht in den Code der Datei master.cfg klettern müssen, wurden im Hauptskript des Programms rac_gui.tcl im Header Zeilen mit der aktuellen Version und Version hinzugefügt:
Und basierend auf diesen Zeilen nummeriert Buildbot die Pakete. Verwenden Sie zum Abrufen von Daten den grep-Aufruf der Konsole. In Buildbot können Sie einfach keine Variablen für "Worker" definieren (auf jeden Fall habe ich nicht gefunden, wie). Verwenden Sie dazu Eigenschaften. Das heißt, Fügen Sie im Assemblierungsprozess die Schritte zum Bestimmen der Version und des Releases hinzu und legen Sie entsprechend die Versions- und Release-Eigenschaften fest. Eigenschaften können auf verschiedene Arten festgelegt werden. In diesem Fall handelt es sich um einen Aufruf eines Konsolenbefehls:
Ersetzen Sie die erhaltenen Werte durch Aufrufen von util.Interpolate ().
Da der Host auch für die manuelle Zusammenstellung von Paketen verwendet wird, erfolgt die Zusammenstellung entlang von Standardpfaden.
Verwenden Sie den Standard-Sed-Aufruf, d. H. Der Befehl ersetzt die Werte in der Spezifikationsdatei durch die erforderlichen
Wir kopieren das fertig zusammengestellte Paket und archivieren es mit den Quellcodes an den Master. Sie können jedoch sofort Dateien von Ihrem Desktop in Ihr Repository oder Ihre Website kopieren.
Im Assistenten starten wir den Prozess des Kopierens der gesammelten Pakete auf das FTP-Hosting. Verwenden Sie dazu das tcl- Skript .
rac_gui_build_RPM.addStep( steps.MasterShellCommand( command=["/usr/local/bin/deploy-ftp.tcl", util.Interpolate("--local-file=/home/buildbot/builds/rac-gui-%(prop:version)s-%(prop:release)s.noarch.rpm"), util.Interpolate("--remote-file=uploads/rac-gui/rac-gui-%(prop:version)s-%(prop:release)s.noarch.rpm")] ) ) rac_gui_build_RPM.addStep( steps.MasterShellCommand( command=["/usr/local/bin/deploy-ftp.tcl", util.Interpolate("--local-file=/home/buildbot/builds/rac-gui-%(prop:version)s-%(prop:release)s.tar.gz"), util.Interpolate("--remote-file=uploads/rac-gui/rac-gui-%(prop:version)s-%(prop:release)s.tar.gz")] ) )
Darauf mit RPM fertig. Beginnen wir nun mit der Beschreibung des Assemblierungsalgorithmus für das DEB-Paket. Da die Prozesse zum Erstellen von Paketen für verschiedene Systeme unabhängig voneinander sind, werden viele Schritte wiederholt.
rac_gui_build_DEB = util.BuildFactory() rac_gui_build_DEB.addStep(steps.Git( repourl = 'https://bitbucket.org/svk28/rac-gui.git', haltOnFailure = True, submodules = True, mode='full', workdir='build', progress = True) )
Für das RPM-Paket wird ein Teil der folgenden Prozeduren während der Montage von RPM selbst ausgeführt und in der Spezifikation beschrieben. Für Debian müssen Sie dies hier tun:
Und DEB ist fertig, jetzt Windows!
rac_gui_build_WIN = util.BuildFactory() rac_gui_build_WIN.addStep(steps.Git( repourl = 'https://bitbucket.org/svk28/rac-gui.git', haltOnFailure = True, submodules = True, mode='full', workdir='build', progress = True) )
Da Windows kein Grep und Sed hat (oder gibt es das?), Werden wir Powershell verwenden
Um über den Status des Montageprozesses zu informieren, verwenden wir E-Mail
c['services'] = [] template=u'''\ <h4>Build status: {{ summary }}</h4> <p> Worker used: {{ workername }}</p> {% for step in build['steps'] %} <p> {{ step['name'] }}: {{ step['result'] }}</p> {% endfor %} <p><b> -- The Buildbot</b></p> ''' mailNotifier = reporters.MailNotifier(fromaddr="builder@domain.ru", sendToInterestedUsers=False, mode=('all'), extraRecipients=["admin@domain.ru"], relayhost="mail.domain.ru", smtpPort=587, smtpUser="builder@domain.ru", smtpPassword="******", messageFormatter=reporters.MessageFormatter( template=template, template_type='html', wantProperties=True, wantSteps=True)) c['services'].append(mailNotifier)
Wir speichern die Datei und Sie können versuchen, den Assistentendienst zu starten:
systemctl restart buildbot-master
Im Protokoll überprüfen wir, ob mit der Konfiguration alles in Ordnung ist und alles wie gewohnt funktioniert. Alle unsere Mitarbeiter sollten sich jetzt verbinden, wie im Protokoll '' '' '/home/buildbot/master/twistd.log' '' 'berichtet wird:
2019-07-24 16:50:35+0300 [-] Loading buildbot.tac... 2019-07-24 16:50:35+0300 [-] Loaded. 2019-07-24 16:50:35+0300 [-] twistd 19.2.1 (/usr/bin/python3.6 3.6.8) starting up. 2019-07-24 16:50:35+0300 [-] reactor class: twisted.internet.epollreactor.EPollReactor. 2019-07-24 16:50:35+0300 [-] Starting BuildMaster -- buildbot.version: 2.3.1 2019-07-24 16:50:35+0300 [-] Loading configuration from '/home/buildbot/master/master.cfg' 2019-07-24 16:50:36+0300 [-] /usr/local/lib/python3.6/site-packages/buildbot/config.py:90: buildbot.config.ConfigWarning: [0.9.0 and later] `buildbotNetUsageData` is not configured and defaults to basic. This parameter helps the buildbot development team to understand the installation base. No personal information is collected. Only installation software version info and plugin usage is sent. You can `opt-out` by setting this variable to None. Or `opt-in` for more information by setting it to "full". 2019-07-24 16:50:36+0300 [-] Setting up database with URL 'sqlite:/state.sqlite' 2019-07-24 16:50:36+0300 [-] setting database journal mode to 'wal' 2019-07-24 16:50:36+0300 [-] adding 1 new services, removing 0 2019-07-24 16:50:36+0300 [-] adding 1 new change_sources, removing 0 2019-07-24 16:50:36+0300 [-] gitpoller: using workdir '/home/buildbot/master/gitpoller-work' 2019-07-24 16:50:36+0300 [-] adding 3 new builders, removing 0 2019-07-24 16:50:36+0300 [-] adding 1 new schedulers, removing 0 2019-07-24 16:50:36+0300 [-] initializing www plugin 'waterfall_view' 2019-07-24 16:50:36+0300 [-] initializing www plugin 'console_view' 2019-07-24 16:50:36+0300 [-] initializing www plugin 'grid_view' 2019-07-24 16:50:36+0300 [-] NOTE: www plugin 'sitenav' is installed but not configured 2019-07-24 16:50:36+0300 [-] initializing www plugin 'waterfall_view' 2019-07-24 16:50:36+0300 [-] initializing www plugin 'console_view' 2019-07-24 16:50:36+0300 [-] initializing www plugin 'grid_view' 2019-07-24 16:50:36+0300 [-] NOTE: www plugin 'sitenav' is installed but not configured 2019-07-24 16:50:36+0300 [-] BuildbotSite starting on 80 2019-07-24 16:50:36+0300 [-] Starting factory <buildbot.www.service.BuildbotSite object at 0x7fe31c2657b8> 2019-07-24 16:50:36+0300 [-] adding 3 new workers, removing 0 2019-07-24 16:50:36+0300 [-] PBServerFactory starting on 4000 2019-07-24 16:50:36+0300 [-] Starting factory <twisted.spread.pb.PBServerFactory object at 0x7fe31c147470> 2019-07-24 16:50:37+0300 [-] BuildMaster is running 2019-07-24 16:50:37+0300 [-] buildbotNetUsageData: sending {'installid': 'b6193b126b96689351d2fe95787c5a03fc0879f9', 'versions': {'Python': '3.6.8', 'Buildbot': '2.3.1', 'Twisted': '19.2.1'}, 'platform': {'platform': 'Linux-4.15.18-10- pve-x86_64-with-centos-7.6.1810-Core', 'system': 'Linux', 'machine': 'x86_64', 'processor': 'x86_64', 'python_implementation': 'CPython', 'version': '#1 SMP PVE 4.15.18-32', 'distro': 'centos:7'}, 'plugins': {'buildbot/worker/base/Worker': 3, 'buildbot/config/BuilderConfig': 3, 'buildbot/schedulers/basic/SingleBranchScheduler': 1, 'buildbot/reporters/mail/MailNotifier': 1, 'buildbot/changes/gitpoller/GitPoller': 1, 'buildbot/steps/worker/MakeDirectory': 1, 'buildbot/steps/source/git/Git': 3, 'buildbot/steps/shell/ShellCommand': 9, 'buildbot/steps/package/rpm/rpmbuild/RpmBuild': 1}, 'db': 'sqlite', 'mq': 'simple', 'www_plugins': ['waterfall_view', 'console_view', 'grid_view']} 2019-07-24 16:50:37+0300 [Broker,0,127.0.0.1] worker 'CentOS' attaching from IPv4Address(type='TCP', host='127.0.0.1', port=37332) 2019-07-24 16:50:37+0300 [Broker,0,127.0.0.1] Got workerinfo from 'CentOS' 2019-07-24 16:50:37+0300 [-] bot attached 2019-07-24 16:50:37+0300 [Broker,0,127.0.0.1] Worker CentOS attached to Rac-GUI-RPM-builder 2019-07-24 16:50:37+0300 [-] buildbotNetUsageData: buildbot.net said: ok 2019-07-24 16:50:39+0300 [Broker,1,192.168.55.15] worker 'Windows-10' attaching from IPv4Address(type='TCP', host='192.168.5.145', port=49831) 2019-07-24 16:50:39+0300 [Broker,1,192.168.55.15] Got workerinfo from 'Windows-10' 2019-07-24 16:50:40+0300 [-] bot attached 2019-07-24 16:50:40+0300 [Broker,1,192.168.55.15] Worker Windows-10 attached to Rac-GUI-WIN-builder 2019-07-24 16:50:41+0300 [Broker,2,192.168.55.99] worker 'Debian-10' attaching from IPv4Address(type='TCP', host='192.168.5.9', port=44430) 2019-07-24 16:50:41+0300 [Broker,2,192.168.55.99] Got workerinfo from 'Debian-10' 2019-07-24 16:50:41+0300 [-] bot attached 2019-07-24 16:50:41+0300 [Broker,2,192.168.55.99] Worker Debian-10 attached to Rac-GUI-DEB-builder
Damit ist der Einrichtungsvorgang abgeschlossen. Sie können den aktuellen Status über das Webface anzeigen. Wenn Sie auch Montagefehler sehen können, starten Sie einen eingefrorenen Prozess, wenn etwas schief gelaufen ist usw.
Unmittelbar nach dem Start unserer harten Arbeiter können Sie durch das Menü "Builds" -> "Workers" sehen.
Nach Abschluss des ersten Erstellungsprozesses (d. H. Änderungen am Git-Repository) wird der Status der Prozesse auf der ersten Seite angezeigt.
Wenn Sie die Maus in die gewünschte Zeile stecken, wird eine Seite mit dem aktuellen Status des Prozesses geöffnet, auf der Sie sehen können, was passiert, welche Fehler usw.
Hier können Sie die gesamte Master-Konfiguration übernehmen import os, re from buildbot.plugins import steps, util, schedulers, worker, changes, reporters c= BuildmasterConfig ={} c['workers'] = [ worker.Worker('CentOS', '123456'), worker.Worker('Debian-10', '123456'), worker.Worker('Windows-10', '123456')] c['protocols'] = {'pb': {'port': 4000}} c['change_source'] = [] c['change_source'].append(changes.GitPoller( repourl = 'https://bitbucket.org/svk28/rac-gui.git', project = 'Rac-GUI', branches = True, pollInterval = 600 ))
Material
Bei der Herstellung des Artikels wurden folgende Materialien verwendet: