(Afbeelding door van
Hallo!
Mijn naam is Evgeny Cherkin, ik ben een programmeur in het ontwikkelteam van het mijnbouwbedrijf Polymetal..
Bij het starten van elk groot project begin je je af te vragen: ‘Welke software is het beste voor het onderhoud ervan?’. Een IT-project doorloopt verschillende fasen voordat de volgende versie wordt uitgebracht. Het is goed als de keten van deze fasen is geautomatiseerd. Het geautomatiseerde proces voor het uitbrengen van een nieuwe versie van een IT-project wordt genoemd Continue Integratie. BuildBot en bleek een goede assistent te zijn die dit proces uitvoert.
In dit artikel wil ik een overzicht geven van de mogelijkheden BuildBot. Wat kan deze software? Hoe pak je het aan en hoe bouw je een effectieve werkrelatie op? Onze ervaring kun je ook toepassen door op je eigen machine een werkservice voor het bouwen en testen van je project op te zetten.
Inhoud
Inhoud
1. Waarom BuildBot?
Eerder op Habr-e kwam ik artikelen tegen over de implementatie Continue Integratie met behulp van BuildBot. Bijvoorbeeld, bleek voor mij het meest informatief. Er is een ander voorbeeld — . Deze artikelen kunnen worden aangevuld met , met behulp van 1 bit, gelijk aan 0, ter aanvulling, in het Engels. Samen vormt het een goed startpunt. Nadat je deze artikelen hebt gelezen, wil je zeker meteen iets op BuildBot doen.
Stop! Heeft iemand het ooit in zijn projecten gebruikt? Blijkbaar wel, ze hebben het toegepast in hun taken. Je kunt het vinden het gebruik van BuildBot ook in de codearchieven van Google.
Wat is de reden van mensen die Buildbot? Ведь есть другие инструменты: CruiseControl en Jenkinsgebruikten? Ik zal het zo zeggen. Voor de meeste taken Jenkins is het inderdaad voldoende. Aan de andere kant, BuildBot is het flexibeler, en bovendien worden daar taken net zo eenvoudig opgelost als in Jenkins. Het is aan jou om te kiezen. Maar aangezien we op zoek zijn naar een tool voor een groeiend doelproject, waarom zouden we dan niet kiezen voor degene die, vanuit eenvoudige stappen, een bouwsysteem biedt met interactiviteit en een unieke interface?
Voor degenen wiens doelproject in Python is geschreven, rijst de vraag: „Waarom niet kiezen voor een integratiesysteem met een duidelijke interface volgens de taal die in het project wordt gebruikt?” En hier is het tijd om de voordelen te presenteren. BuildBot.
Dus, onze «instrumentele kwartet». Voor mezelf heb ik vier kenmerken bepaald. BuildBot:
- Het is een open-source framework onder de GPL-licentie.
- Dit is het gebruik van Python als configuratietool en voor het beschrijven van de vereiste acties.
- Het biedt de mogelijkheid om een reactie te ontvangen van de machine waarop de bouw plaatsvindt.
- Ten slotte zijn er minimale vereisten voor de host. Voor implementatie zijn Python en Twisted vereist, en er is geen virtuele machine of Java-machine nodig.
2. Concept geleid door BuildMaster
Centrale positie in de architectuur van taakverdeling is BuildMaster.Het is een service die:
- wijzigingen in de broncodes van het project volgt, commando's verstuurt die de worker-service moet uitvoeren om het project te bouwen en te testen.
- gebruikers op de hoogte stelt van de resultaten van de uitgevoerde acties. wordt geconfigureerd via een bestand.
- Dit bestand bevindt zich in de root. Later laat ik zien hoe deze root wordt aangemaakt. Het bestand zelf
BuildMaster. bevat een Python-script dat oproepen gebruikt. master.cfgHet volgende belangrijke object BuildMaster.heeft de naam master.cfg . Deze service kan op een andere host met een ander besturingssysteem worden uitgevoerd, maar ook op degene waar het draait. BuildBot.
Het kan ook bestaan in een speciaal voorbereide virtuele omgeving met zijn eigen pakketten en variabelen. Deze virtuele omgevingen kunnen worden voorbereid met behulp van Python-tools zoals BuildBot virtualenv, venv. WorkerHet stuurt commando's naar elke worker, die ze op zijn beurt uitvoert. Dit betekent dat het bouwen en testen van het project kan plaatsvinden op BuildMaster.met Windows en op een andere worker met Linux. De checkout van de broncodes van het project vindt plaats op elke.
BuildMaster. . WorkerDus, laten we beginnen. Als host zal ik Ubuntu 18.04 gebruiken. Hierop zal ik één Workeren één
plaatsen. Maar eerst moet Python 3.7 worden geïnstalleerd: sudo apt-get update sudo apt-get install python3.7 WorkerVoor degenen die Python 3.7.2 in plaats van 3.7.1 nodig hebben, kan het volgende worden gedaan:
3. Installatie
sudo apt-get update sudo apt-get install 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 BuildMaster.De volgende stap is het installeren van WorkerTwisted.
-en.
Het uitvoerbare bestand wordt gegenereerd met behulp van
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
De volgende stap is de installatie van Twited en BuildBot, en ook pakketten die extra functionaliteit mogelijk maken BuildBot-a.
/*Все что под 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. Eerste stappen
Tijd om te creëren BuildMaster.. Hij zal in onze map staan /home/habr/master.
mkdir master
buildbot create-master master # Hier creëren we het eigenlijkVolgende stap. Laten we creëren Worker. Hij zal in onze map staan /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Wanneer je Worker, het zal standaard een maken in /home/habr/worker de map met de naam van het project dat is opgegeven in master.cfg. En in de map met de naam van het project zal het een directory creëren build, en verder zal het checkout. De werkdirectory voor Worker-a zal de directory worden /home/habr/yourProject/build.
De 'Gouden' sleutel
En nu hetgene waarvoor ik de vorige alinea heb geschreven: het script dat Master zich zal vereisen dat Worker-a mogelijk moet maken om dit directory op afstand uit te voeren, zal niet worden uitgevoerd, omdat het script geen rechten heeft om te starten. Om de situatie te verhelpen, is er een sleutel nodig —umask=0o22, die de schrijfbevoegdheid in deze directory beperkt, maar de uitvoerrechten zal behouden. En dat is precies wat we nodig hebben.
BuildMaster. en Worker verbonden met elkaar. Het kan gebeuren dat de verbinding verbroken wordt en Worker een tijd wacht op een reactie van BuildMaster.-a. Als er geen antwoord komt, wordt de verbinding opnieuw opgestart. De sleutel —keepalive=60 is precies nodig om de tijd op te geven waarop connect de verbinding opnieuw opstart.
5. Configuratie. Stapsgewijs recept
Configuratie BuildMaster. wordt aan de kant van de machine waar we het commando hebben uitgevoerd create-master. In ons geval is dat de map /home/habr/master. Het configuratiebestand master.cfg bestaat nog niet, echter heeft het commando al het bestand aangemaakt master.cmg.sample. Het is nodig om het te hernoemen naar master.cfg.sample in master.cfg
mv master.cfg.sample master.cfgLaten we dit openen master.cfg. En gaan we bekijken waaruit het bestaat. Daarna proberen we ons eigen configuratiebestand te maken.
master.cfg
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
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"]))
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": "."}))
c['builders'] = []
c['builders'].append(
util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
c['services'] = []
c['title'] = "Hello World CI"
c['titleURL'] = "https://buildbot.github.io/hello-world/"
c['buildbotURL'] = "http://localhost:8010/"
c['www'] = dict(port=8010,
plugins=dict(waterfall_view={}, console_view={}, grid_view={}))
c['db'] = {
'db_url' : "sqlite:////state.sqlite",
}
5.1 BuildmasterConfig
c = BuildmasterConfig = {} BuildmasterConfig — basisconfiguratie woordenboek. Dit moet verplicht worden opgenomen in het configuratiebestand. Voor gebruiksgemak in de configuratiecode wordt een alias hiervoor gemaakt. «c». De namen in c[«keyFromDist»] zijn vaste elementen voor interactie met BuildMaster.. Voor elke sleutel is de overeenkomstige objectwaarde opgenomen.
5.2 workers
c['workers'] = [worker.Worker("example-worker", "pass")]Deze keer specificeren we BuildMaster.-een lijst van Worker-en. Wij Worker hebben gecreëerd , door you-worker-name en password. Nu moeten we deze ook aangeven in plaats van example-worker en pass .
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))
Via de sleutel change_source van het c-woordenboek krijgen we toegang tot de lijst waar het object dat de codebasis van het project bewerkt moet worden geplaatst. In het voorbeeld wordt een Git-repository gebruikt, die periodiek wordt gecontroleerd.
De eerste parameter is het pad naar uw repository.
workdir is het pad naar de map waartegenover Worker-a ten opzichte van het pad /home/habr/worker/yourProject/build de git de lokale versie van de repository zal opslaan.
branch bevat de specifieke tak in de repository die in de gaten moet worden gehouden.
pollInterval bevat het aantal seconden waarna BuildMaster. de repository wordt gecontroleerd op wijzigingen.
Er zijn verschillende methoden om wijzigingen in de projectrepository te volgen.
De eenvoudigste methode is Polling, wat inhoudt dat BuildMaster. periodiek de server met de repository aan. In het geval dat commit de wijzigingen in de repository zijn weerspiegeld, BuildMaster. zal met enige vertraging een intern object creëren Change en zal dit naar de gebeurtenis handler sturen Scheduler, die de stappen voor het bouwen en testen van het project opstart op Worker-e. Onder deze stappen zal worden vermeld update repository. Precisie op Worker-e zal een lokale kopie van de repository worden gemaakt. De details van dit proces worden verderop in de volgende twee secties onthuld ( en ).
Een nog eleganter methode om wijzigingen in de repository te volgen, is door directe berichten van de server waarop deze is gehost naar BuildMaster.-u over de wijzigingen in de projectcode te verzenden. In dit geval, zodra de ontwikkelaar commit, zal de server met de projectrepository een bericht sturen BuildMaster.-u. Deze zal vervolgens het bericht opvangen en een object aanmaken PBChangeSource. Dit object zal worden doorgegeven aan Scheduler, dat de stappen voor het bouwen van het project en het testen daarvan activeert. Een belangrijk onderdeel van deze methode is de interactie met hook-scripts op de server in de repository. In het script hook-a, dat verantwoordelijk is voor het verwerken van acties bij commit-e, moet de utility sendchange worden aangeroepen en het netwerkadres van BuildMaster.-a opgegeven. Ook moet de netwerkpoort worden opgegeven die zal luisteren naar PBChangeSource. PBChangeSource, wat trouwens onderdeel is van BuildMaster.-a. Deze methode vereist rechten admin-a op de server waar de projectrepository zich bevindt. Van te voren moet een backup van de repository worden gemaakt.
5.4 shedulers
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"]))
schedulers is een element dat fungeert als trigger die de gehele keten voor het bouwen en testen van het project op gang brengt.
De wijzigingen die zijn vastgelegd change_source, zijn omgevormd in het werkproces BuildBot-a in een object Change en nu vormt elk Sheduler op basis daarvan verzoeken om het bouwproces van het project te starten. Het bepaalt echter ook wanneer deze verzoeken verder in de wachtrij worden doorgegeven. Het object Builder houdt een wachtrij van verzoeken bij en volgt de status van de huidige bouw op een afzonderlijke Worker-e. Builder is er zowel op BuildMaster.-e als op Worker-e. Het stuurt ook van BuildMaster.-a naar Worker-a al een specifieke build — serie stappen die moeten worden uitgevoerd.
We zien dat in het huidige voorbeeld er schedulers 2 stuks worden aangemaakt. Daarbij heeft elke een eigen type.
SingleBranchScheduler – een van de populairste types schema's. Het houdt een tak in de gaten en wordt geactiveerd bij een vastgelegde wijziging daarin. Wanneer het veranderingen ziet, kan het het verzenden van een bouwverzoek uitstellen (uitstel voor de periode die is opgegeven in een speciale parameter treeStableTimer). In naam wordt de naam van het schema opgegeven, die zal verschijnen in de BuildBot-webinterface. In ChangeFilter wordt een filter opgegeven, waarna wijzigingen in de tak het schema aanzetten om een bouwverzoek te verzenden. In builderNames wordt de naam opgegeven , bedoeld voor het samenstellen van pakketten en distributies. Voor aarch64 is een live-variant samengesteld, gelijk aan x86_64; voor beide architecturen zijn rootfs-afbeeldingen voor RPi4 en qemu-afbeeldingen samengesteld.-a, die we zo meteen zullen instellen. De naam in ons geval zal dezelfde zijn als de projectnaam: yourProject.
ForceScheduler is een heel eenvoudig ding. Dit type schema wordt geactiveerd met een muisklik via BuildBot-webinterface. De parameters hebben dezelfde betekenis als in SingleBranchScheduler.
P.S. №3. Misschien heeft het nog nut
Periodic is een schema dat wordt geactiveerd met een bepaalde vaste tijdsinterval. De aanroep van zijn functie ziet er ongeveer zo uit:
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 geeft de tijd van deze periodiciteit in seconden op.
BuildFactory maakt een specifieke build, die later , bedoeld voor het samenstellen van pakketten en distributies. Voor aarch64 is een live-variant samengesteld, gelijk aan x86_64; voor beide architecturen zijn rootfs-afbeeldingen voor RPi4 en qemu-afbeeldingen samengesteld. wordt verzonden naar Workerwordt een tabel met wijzigingen en instructies voor de overgang naar de nieuwe configuratie gegeven. Voor meer informatie, zie BuildFactory hier worden de stappen opgegeven die moeten worden uitgevoerd Worker-u. Stappen worden toegevoegd via de aanroep van de methode addStep
De eerste toegevoegde stap in dit voorbeeld is git clean -d -f -f –x, dan git checkout. Deze acties zijn vastgelegd in de parameter methode, die niet expliciet is aangegeven, maar waarvan de standaardwaarde wordt verondersteld fresh. De parameter mode=’incremental’ geeft aan dat bestanden in de directory waar de chechout, terwijl diegene die niet in de repository staan, onaangeroerd blijven.
De tweede toegevoegde stap is de aanroep van het script trial met de parameter hello aan de zijde van Worker-a vanuit de directory /home/habr/worker/yourProject/build c met de omgevingsvariabele PATHONPATH=… Op deze manier kun je je scripts schrijven en ze uitvoeren aan de zijde van Worker-a via de stap util.ShellCommand. Deze scripts kunnen direct in de repository worden geplaatst. Dan tijdens chechout-e komen ze in /home/habr/worker/yourProject/build. Echter, er zijn dan twee “maar”:
- Worker moet worden gemaakt met de sleutel zodat het de uitvoeringsrechten na checkout-a.
- Bij git push-e van deze scripts niet blokkeert, moet de eigenschap worden opgegeven exacutable, zodat daarna bij chechout-e de uitvoeringsrechten van het script Git niet verloren gaan.
5.6 builders
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Wat het is Builder werd verteld . Nu zal ik wat meer vertellen over hoe je het kunt maken. BuilderConfig is een constructor , bedoeld voor het samenstellen van pakketten en distributies. Voor aarch64 is een live-variant samengesteld, gelijk aan x86_64; voor beide architecturen zijn rootfs-afbeeldingen voor RPi4 en qemu-afbeeldingen samengesteld.. Er kunnen verschillende van deze constructeurs zijn in c[‘builders’] aangezien dit een lijst van objecten kan zijn , bedoeld voor het samenstellen van pakketten en distributies. Voor aarch64 is een live-variant samengesteld, gelijk aan x86_64; voor beide architecturen zijn rootfs-afbeeldingen voor RPi4 en qemu-afbeeldingen samengesteld. . Laten we het voorbeeld iets herschrijven om het meer in lijn te brengen met onze taak. BuildBotc['builders'] = [] c['builders'].append(util.BuilderConfig(name="yourProject", workernames=["yourWorkerName"], factory=factory))
Nu zal ik de parameters uitleggen
geeft de naam aan BuilderConfig.
naam -a. Hier hebben we het genoemd , bedoeld voor het samenstellen van pakketten en distributies. Voor aarch64 is een live-variant samengesteld, gelijk aan x86_64; voor beide architecturen zijn rootfs-afbeeldingen voor RPi4 en qemu-afbeeldingen samengesteld.. Dit betekent dat op yourProject-e dit specifieke pad zal worden aangemaakt Workerheet /home/habr/worker/yourProject/build. Sheduler precies naar deze naam. , bedoeld voor het samenstellen van pakketten en distributies. Voor aarch64 is een live-variant samengesteld, gelijk aan x86_64; voor beide architecturen zijn rootfs-afbeeldingen voor RPi4 en qemu-afbeeldingen samengesteld. workernames
bevat een lijst -s. Elke hiervan moet toegevoegd worden aan Workerc[‘workers’] factory.
is de specifieke , waarmee het is geassocieerd build. Het zal een object sturen , bedoeld voor het samenstellen van pakketten en distributies. Voor aarch64 is een live-variant samengesteld, gelijk aan x86_64; voor beide architecturen zijn rootfs-afbeeldingen voor RPi4 en qemu-afbeeldingen samengesteld.om alle stappen uit te voeren die deel uitmaken van deze build en een werkende opdracht krijgen. Worker Hier is de architectuur van het project dat ik voorstel te implementeren via build-a.
6. Voorbeeld van een eigen configuratie
Voor versiecontrole zullen we gebruiken BuildBot
.
svn . Het repository zal zich in een of andere cloud bevinden. Hier is het adres van deze cloudsvn.host/svn/yourProject/trunk , passwd: . Het repository zal zich in een of andere cloud bevinden. Hier is het adres van deze cloud . Scripts, die de stappen vertegenwoordigen gebruiker-a zullen ook in de tak liggen password, in een aparte map buildbuildbot/worker_linux . Het repository zal zich in een of andere cloud bevinden. Hier is het adres van deze cloud. Deze scripts bevinden zich in het repository met een opgeslagen eigenschap executablewerken op één host project.host.
BuildMaster. en Worker bewaart zijn bestanden in de map bewaart ze echter op het volgende pad .BuildMaster. . De communicatie tussen processen /home/habr/master. Worker -a en /home/habr/worker-a vindt plaats via poort 4000 met het protocol BuildMaster.-a, dat wil zeggen Worker‘pb’ BuildBotprotocol. Het doelproject is volledig geschreven in Python. De taak is om zijn wijzigingen te volgen, een uitvoerbaar bestand te maken, documentatie te genereren, tests uit te voeren. In geval van een failure moeten alle ontwikkelaars een e-mailbericht ontvangen over het feit dat er een mislukte actie is gebeurd. Webweergave
hun we verbinden op poort 80 voor
. Apatch hoeft niet per se geïnstalleerd te worden. In de bibliotheek BuildBot twisted bewaart ze echter op het volgende padzit al een webserver, die wordt gebruikt. Voor het opslaan van interne informatie voor BuildBot Voor e-mail verzending is een host nodig
smtp.your.domain BuildBot zullen we gebruiken sqlite.
— daarop is het toegestaan om e-mails te verzenden vanaf het adres projectHost@your.domain zonder authenticatie. Ook op de host ‘smtp ‘ luistert het protocol op poort 1025.Er zijn twee betrokken partijen in het proces: . admin beheert
. user is de persoon die admin en gebruiker-en uitvoert. BuildBotHet uitvoerbare bestand wordt gegenereerd via commit-ies.
Executable bestand wordt gegenereerd via pyinstaller. De documentatie wordt gegenereerd via doxygen.
Voor deze architectuur heb ik het volgende geschreven master.cfg:
master.cfg
import os, re
from buildbot.plugins import steps, util, schedulers, worker, changes, reporters
c= BuildmasterConfig ={}
c['workers'] = [ worker.Worker('yourWorkerName', 'password') ]
c['protocols'] = {'pb': {'port': 4000}}
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)
projectHost_build = util.BuildFactory()
cleanProject = steps.ShellCommand(name="Clean",
command=["buildbot/worker_linux/pyinstaller_project", "clean"]
)
buildProject = steps.ShellCommand(name="Build",
command=["buildbot/worker_linux/pyinstaller_project", "build"]
)
doxyProject = steps.ShellCommand(name="Update Docs",
command=["buildbot/worker_linux/gendoc", []]
)
testProject = steps.ShellCommand(name="Tests",
command=["python","tests/utest.py"],
env={'PYTHONPATH': '.'}
)
projectHost_build.addStep(checkout)
projectHost_build.addStep(cleanProject)
projectHost_build.addStep(buildProject)
projectHost_build.addStep(doxyProject)
projectHost_build.addStep(testProject)
c['builders'] = [
util.BuilderConfig(name="yourProject", workername='yourWorkerName', factory=projectHost_build)
]
template_html=u'''
<h4>Status van de gebouwde release: {{ summary }}</h4>
<p>Gebruikte service voor de bouw: {{ workername }}</p>
<p>Project: {{ projects }}</p>
<p>Om de beheerdersinterface te bekijken, gaat u naar de link: {{ buildbot_url }}</p>
<p>Om de bouwresultaten te bekijken, gaat u naar de link: {{ build_url }}</p>
<p>Met WinSCP kunt u verbinding maken met de server op ip:xxx.xx.xxx.xx. Log in met habr/password om het gebouwde uitvoerbare bestand van de directory ~/worker/yourProject/build/dist te halen.</p>
<p><b>De bouw werd uitgevoerd via 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]
c['title'] = "Het proces van bouwen"
c['titleURL'] = "http://project.host:80/"
c['buildbotURL'] = "http://project.host"
c['www'] = dict(port=80,
plugins=dict(waterfall_view={}, console_view={}, grid_view={}))
c['db'] = {
'db_url' : "sqlite://state.sqlite"
}
Om te beginnen moet je BuildMaster.-a, dat wil zeggen Worker-a. Vervolgens dit bestand invoegen master.cfg in /home/habr/master.
De volgende stap is om de service te starten BuildMaster.-a
sudo buildbot start /home/habr/master
Vervolgens de service starten Worker-a
buildbot-worker start /home/habr/worker
Klaar! Nu Buildbot zal het wijzigingen volgen en reageren op commit-u in . Het repository zal zich in een of andere cloud bevinden. Hier is het adres van deze cloud, de bouw- en teststappen uitvoeren voor het bovenstaande architectuurproject.
Hieronder zal ik enkele kenmerken van de bovenstaande master.cfg.
6.1 Op weg naar mijn master.cfg
Tijdens het schrijven van je master.cfg zullen er waarschijnlijk veel fouten optreden, dus het is noodzakelijk om het logbestand te lezen. Dit wordt opgeslagen zowel op BuildMaster.-e c met een absoluut pad /home/habr/master/twistd.log, alsook aan de kant Worker-a met een absoluut pad /home/habr/worker/twistd.log. Bij het lezen van de fouten en het corrigeren ervan moet de service BuildMaster.-a opnieuw worden opgestart. Dit is hoe je dat doet:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Werken met svn
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)
Laten we eerst kijken naar svn_poller. Dit is dezelfde interface die regelmatig de repository elke minuut pollt. In dit geval svn_poller wordt er alleen naar de branch trunk. De mysterieuze parameter split_file=util.svn.split_file_alwaystrunk stelt de regels in: hoe de folderstructuur . Het repository zal zich in een of andere cloud bevinden. Hier is het adres van deze cloud in branches te splitsen. Het biedt ook relatieve paden. Op zijn beurt split_file_alwaystrunk vereenvoudigt het proces door aan te geven dat er alleen trunk.
In Schedulers wordt aangegeven ChangeFilter, die ziet None en associeert met de branch trunk volgens de gegeven associatie via split_file_alwaystrunk. Reagerend op wijzigingen in trunk, start het , bedoeld voor het samenstellen van pakketten en distributies. Voor aarch64 is een live-variant samengesteld, gelijk aan x86_64; voor beide architecturen zijn rootfs-afbeeldingen voor RPi4 en qemu-afbeeldingen samengesteld. c met de naam yourProject.
properties is hier nodig zodat de admin resultaten van de bouw- en testprocessen ontvangt als eigenaar van het proces.
Stap build-a checkout kan een volledige verwijdering van alle bestanden in de lokale versie van de repository doen Worker-a. Aansluitend uitvoerige svn update. De modus is ingesteld via de parameter mode=full, method=fresh. De parameter haltOnTailure geeft aan dat als svn update Als er een fout optreedt, moet het hele proces van samenstelling en testen worden onderbroken, omdat verdere acties geen zin hebben.
6.3 U heeft een bericht: reporters is gemachtigd om aan te geven
journalisten is een meldingsservice per e-mail.
template_html=u'''
<h4>Status van de gebouwde release: {{ summary }}</h4>
<p>Gebruikte service voor de bouw: {{ workername }}</p>
<p>Project: {{ projects }}</p>
<p>Om de beheerdersinterface te bekijken, gaat u naar de link: {{ buildbot_url }}</p>
<p>Om de bouwresultaten te bekijken, gaat u naar de link: {{ build_url }}</p>
<p>Met WinSCP kunt u verbinding maken met de server op ip:xxx.xx.xxx.xx. Log in met habr/password om het gebouwde uitvoerbare bestand van de directory ~/worker/yourProject/build/dist te halen.</p>
<p><b>De bouw werd uitgevoerd via 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]
Het kan berichten versturen .
MailNotifier maakt gebruik van e-mail voor het verzenden van meldingen.
template_html stelt de tekstsjabloon voor de verzending in. Voor het maken van de lay-out wordt HTML gebruikt. Het is aangepast door de engine (vergelijkbaar met django). BuildBot heeft een set variabelen waarvan de waarden in de sjabloon worden geplaatst tijdens het opstellen van de tekst van het bericht. Deze variabelen zijn ingeschreven in {{ dubbele accolades }}. Bijvoorbeeld, samenvatting geeft de status van voltooide operaties weer, dat is success of failure. En projecten zal worden weergegeven yourProject. Zo kan met behulp van besturingscommando's in jinja2, variabelen BuildBot-a en string formattering tools van python een vrij informatief bericht worden gecreëerd.
MailNotifier bevat de volgende argumenten.
fromaddr is het adres van waaruit de verzending zal plaatsvinden.
sendToInterestedUsers=True verzendt een bericht naar de eigenaar en de gebruiker die commit.
lookup is een suffix dat moet worden toegevoegd aan de namen van gebruikers die de mailing ontvangen. Zodat admin de gebruiker de mailing ontvangt op admin@your.domain.
relayhost stelt de naam van de host in waarop de server is geopend Er zijn twee betrokken partijen in het proces:, a smptPort stelt het poortnummer in dat wordt beluisterd Er zijn twee betrokken partijen in het proces: server.
mode=«warning» geeft aan dat de verzending alleen moet plaatsvinden in het geval dat er minstens één stap is build-a, die eindigt met de status failure of warning. In geval van success is verzending niet nodig.
extraRecipients bevat een lijst van personen naar wie de mailing moet worden verzonden, naast de eigenaar en de persoon die commit.
messageFormatter is een object dat het formaat van het bericht, de sjabloon en de set variabelen die beschikbaar zijn in jinja2. Parameters zoals wantProperties=True en wantSteps=True stellen deze set beschikbare variabelen in.
s[‘services’]=[sendMessageToAll] geeft een lijst van diensten die beschikbaar zijn, waaronder onze reporter.
We hebben het gedaan! Mijn felicitaties.
We hebben onze eigen configuratie gecreëerd en zagen de functionaliteit waarvoor hij geschikt is. BuildBot. Dit is denk ik voldoende om te begrijpen of dit hulpmiddel nodig is voor uw project. Is het interessant voor u? Zal het nuttig zijn? Is het gemakkelijk om mee te werken? Dan was het niet voor niets dat ik dit artikel schreef.
En nog iets. Ik zou willen dat de professionele gemeenschap die gebruikmaakt van BuildBot, breder zou worden, dat handleidingen werden vertaald en dat er nog meer voorbeelden zouden komen.
Iedereen bedankt voor de aandacht. Veel succes.
Bron: habr.com
