(Imazhi nga from
Përshëndetje!
Unë quhem Evgeny Cherkin, unë jam programues i ekipit të zhvilluesve në një kompani minerare Polymetal.
Duke filluar çdo projekt të madh, fillon të mendosh: "Cili softuer është më i mirë për mirëmbajtjen e tij?". Një projekt IT, përpara se të lëshojë një version të ri, kalon një sërë fazash. Është mirë kur zinxhiri i këtyre fazave është i automatizuar. Procesi automatizuar për lëshimin e një versioni të ri të një projekti IT quhet Continuous Integration. BuildBot për ne është bërë një ndihmës i mirë që realizon këtë proces.
Në këtë artikull vendosa të paraqes një përmbledhje të mundësive të BuildBot. Çfarë është në gjendje të bëjë ky softuer? Si të hyjmë në të dhe si të ndërtojmë marrëdhënie të mira EFEKTIVE me të? Eksperienca jonë mund të aplikohet edhe tek ju, duke krijuar një shërbim funksional të ndërtimit dhe testimit të projektit tuaj në makinat tuaja.
Përmbajtja
Përmbajtja
1. Pse BuildBot?
Më parë në habr-e kam parë artikuj rreth implementimit Continuous Integration duke përdorur BuildBot. Për shembull, më duket më informativ. Ka një shembull tjetër — . Këto artikuj mund të shoqërohen , dhe në rrugë, në anglisht. Në këtë mënyrë, krijohet një pikë e mirë fillestare. Pasi të lexoni këto artikuj, me siguri do të dëshironi të bëni diçka në BuildBot .
Ndalo! A ka dikush përdorur vërtet atë në projektet e tij? Raste e kësaj janë, kanë aplikuar atë në detyrat e tyre. Mund të gjenden përdorimit BuildBot edhe në arkivat e kodit të Google.
Pra, cila është logjika e njerëzve që përdorin Buildbot? Ведь есть другие инструменты: CruiseControl dhe Jenkins? Do të përgjigjem kështu. Për shumicën e detyrave Jenkins në fakt do të mjaftonte. Në anën tjetër, BuildBot — është më i adaptueshëm, dhe për këtë arsye detyrat atje zgjidhen po aq lehtë sa në Jenkins. Në fund, zgjedhja është e juaja. Por pasi jemi duke kërkuar një instrument për një projekt që po zhvillohet, pse të mos zgjidhni atë që do t'ju lejojë, duke u nisur nga hapat e thjeshtë, të krijoni një sistem ndërtimi me interaktivitet dhe një ndërfaqe unike.
Ata, që projekti i tyre është shkruar në python, kanë pyetje: "Pse të mos zgjidhni një sistem integrimi, në të cilin ka një ndërfaqe të ngjashme me gjuhën e përdorur në projekt?". Dhe tani është koha të paraqesim avantazhet e BuildBot.
Pra, katër karakteristikat tona. Kam përcaktuar katër karakteristika BuildBot:
- Ky është një framework me kod të hapur nën licencën GPL
- Ky është përdorimi i python si mjet për konfigurim dhe përshkrimin e veprimeve të nevojshme
- Kjo është mundësia për të marrë përgjigje nga makina, në të cilën ndodh ndërtimi
- Kjo, më në fund, ka kërkesa minimale për hostin. Për implementimin kërkohet python dhe twisted, dhe nuk është e nevojshme një makinë virtuale dhe java-makina.
2. Koncepti nën drejtimin e BuildMaster
Vendi qendror në arkitekturën e shpërndarjes së detyrave zë BuildMaster. Ai përfaqëson një shërbim që:
- ndjek ndryshimet në pemën e burimeve të projektit
- dërgon komandat që duhen ekzekutuar nga shërbimi Worker për ndërtimin dhe testimin e projektit
- informon përdoruesit në lidhje me rezultatet e veprimeve të ekzekutuara
BuildMaster konfigurohet përmes një skedari master.cfg. Ky skedar ndodhet në rrënjë BuildMaster. Më vonë do të tregoj se si krijohet kjo rrënjë. Skedari vetë master.cfg përmban një skenar python, që përdor thirrje BuildBot.
Objekti tjetër më i rëndësishëm BuildBot ka emrin Punëtori. Ky shërbim mund të ekzekutohet në një host tjetër me një OS tjetër, ose në atë që është BuildMaster. Ai gjithashtu mund të ekzistojë në një mjedis virtual të përgatitur me paketat dhe variablat e tij. Këto mjedise virtuale mund të përgatiten duke përdorur utilitetet python si vertualenv, venv.
BuildMaster transmiton komandat çdo Punëtori-i, dhe ai, nga ana e tij, i ekzekuton. Pra, ndodhi që procesi i ndërtimit dhe testimit të projektit mund të jetë në Punëtori-a nën menaxhimin e Windows dhe në një Worker tjetër nën menaxhimin e linux.
Checkout i burimeve të kodit të projektit ndodh në çdo Punëtori-e.
3. Instalimi
Pra, të shkojmë. Si host do përdor Ubuntu 18.04. Atë do ta përdor për një BuildMaster-a dhe një Punëtori-a. Por përpara se gjithçka, duhet të instalohet python3.7:
sudo apt-get update
sudo apt-get install python3.7
Për ata që kanë nevojë për python3.7.2 në vend të 3.7.1, mund të bëni si më poshtë:
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
Hapi tjetër është të instaloni Twisted dhe BuildBot, si dhe paketat që lejojnë aktivizimin e funksionaliteteve shtesë 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. Hapat e parë
Koha për të krijuar BuildMaster. Ai do të jetë në dosjen tonë /home/habr/master.
mkdir master
buildbot create-master master # Këtu e krijojmëHapi tjetër. Të krijojmë Punëtori. Ai do të jetë në dosjen tonë /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Kur ju të lançoni Punëtori, ai automatikisht do të krijojë një /home/habr/worker folder me emrin e projektit që është përcaktuar në master.cfg. Dhe brenda folders me emrin e projektit do të krijojë një drejtor ndërto, dhe më pas do të bëjë checkout. Katalogu punues për Punëtori-in do të jetë drejtorija /home/habr/yourProject/build.
çelësi ‘Ari’
Dhe tani, për arsyen për të cilën shkrova paragrafin e mëparshëm: skripti që Master kërkon nga Punëtori-i të bëjë në mënyrë të largët në këtë drejtor, nuk do të ekzekutohet, pasi skripti nuk ka të drejta për të ekzekutuar. Për të rregulluar këtë, do të kërkohet çelësi —umask=0o22, i cili ndalon shkrimin në këtë drejtor, por lë të drejtat e ekzekutimit. Dhe ky është pikërisht ajo që na nevojitet.
BuildMaster dhe Punëtori krijojnë lidhje me njëri-tjetrin. Ndonjëherë, ajo ndërpritet dhe Punëtori prit një kohë për përgjigje nga BuildMaster-i. Nëse nuk ka përgjigje, lidhej përsëri. Çelësi —keepalive=60 për të treguar kohën, pas së cilës lidhu risjell.
5. Konfigurimi. Receta hap pas hapi
Konfigurimi BuildMaster bëhet nga ana e makinës, ku ne ekzekutuam komandën create-master. Në rastin tonë — kjo është katalogu /home/habr/master. Skedari i configurimit master.cfg ende nuk ekziston, megjithatë komanda tashmë krijoi skedarin master.cmg.sample. Duhet ta riemërojmë në master.cfg.sample në master.cfg
mv master.cfg.sample master.cfgDo ta hapim këtë master.cfg. Dhe do të analizojmë nga çfarë përbëhet. Pas kësaj do të përpiqemi të krijojmë skedarin tonë të konfigurimit.
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 — një fjalor bazë për skedarin e konfigurimit. Ai duhet të përdoret patjetër në skedarin e konfigurimit. Për lehtësinë e përdorimit në kodin e konfigurimit krijohet një pseudonim «c». Emrat në c[«keyFromDist»] janë elemente fikse për ndërveprimin me BuildMaster. Për secilin çelës, si vlerë vendoset objekti përkatës.
5.2 punonjësit
c['workers'] = [worker.Worker("example-worker", "pass")]Tani ne po tregojmë BuildMaster-n një listë prej Punëtori-ve. Ne Punëtori e kemi krijuar , duke treguar you-worker-name dhe password. Tani duhet t'i tregojmë ato në vend të example-worker dhe pass .
5.3 burimi_i_ndryshimeve
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
Me çelësin change_source në fjalorin c marrim qasje në listën ku duhet të vendosim objektin që po kërkon repo me kodin burimor të projektit. Në shembull përdoret repo Git që ndiqet me një periudhë të caktuar.
Argumenti i parë është rruga në repot tuaj.
workdir përfaqëson rrugën e folderit ku në anën e Punëtori-it në lidhje me rrugën /home/habr/worker/yourProject/build Git do të ruajë versionin lokal të repot.
branch përmban degën specifike në repo që duhet të ndiqet.
pollInterval përmban numrin e sekondave, pas të cilave BuildMaster do të kontrollojë repo për ndryshime.
Ka disa metoda për të ndjekur ndryshimet në repo-n e projektit.
Metoda më e thjeshtë është Polling, që nënkupton se BuildMaster kontrollon periodicisht serverin me repo. Në rast se commit reflekton ndryshime në repo, atëherë BuildMaster me një vonesë të vogël do të krijohet objekti brenda Change dhe të dërgohet në trajtuesin e ngjarjeve Planifikuesi, i cili do të aktivizojë hapat për ndërtimin dhe testimin e projektit në Punëtori-in. Ndër këto hapa do të jetë e përfshirë update repo. Pikërisht në Punëtori-in do të krijohet një kopje lokale e repo-s. Detajet e këti procesi do të shpalosen më poshtë në dy seksionet e ardhshme. ( dhe ).
Një metodë edhe më elegante për të ndjekur ndryshimet në repo është dërgimi i drejtpërdrejtë i mesazheve nga serveri, ku ai është vendosur, për BuildMaster-in për ndryshimin e kodit burimor të projektit. Në këtë rast, sapo zhvilluesi të bëjë commit, serveri me repo-n e projektit do dërgojë një mesazh BuildMaster-it. Dhe ai, nga ana e tij, do ta kapë duke krijuar objektin PBChangeSource. Pas kësaj, ky objekt do t'i dërgohet Planifikuesi, i cili aktivizon hapat për ndërtimin dhe testimin e projektit. Një pjesë e rëndësishme e këtij mënyre është puna me skritp-hook-t e serverit në repo. skritp-hook-a, i cili është përgjegjës për përpunimin e veprimeve në commit-e, nevojitet të thërrasim utilit sendchange dhe të specifikojmë adresën rrjetore BuildMaster-a. Duhet gjithashtu të caktosh portin rrjetor që do të dëgjojë PBChangeSource. PBChangeSource, përndryshe, është pjesë e BuildMaster-a. Ky metod do të kërkojë të drejta admin-a në serverin ku ndodhet depoja e projektit. Para kësaj, do të nevojitet të bëhet një backup i depozitës.
5.4 planifikuesit
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 – është një element që vepron si një ndihmës, duke nisur gjithë zinxhirin e ndërtimit dhe testimit të projektit.
Ndryshimet që janë regjistruar change_source, janë transformuar gjatë procesit të punës BuildBot-a në një objekt Change dhe tani çdo Scheduler ndërton kërkesat për nisjen e procesit të ndërtimit të projektit. Megjithatë, ai përcakton gjithashtu kur duhet të dërgohen këto kërkesa më tej në radhë. Objekti Builder mban në të njëjtën radhë kërkesat dhe ndjek gjendjen e ndërtimit aktual në një Punëtori-e. Builder ekziston gjithashtu në BuildMaster-e dhe në Punëtori-e. Ai gjithashtu dërgon me BuildMaster-a një Punëtori-a një seri hapash që duhet të realizohen. ndërto Ne shohim se në shembullin aktual, të tilla
krijohen 2 copa. Cdo njëra ka llojin e vet. schedulers SingleBranchScheduler
– një nga klasat më të njohura të planifikimit. Ai monitoron një degë dhe aktivizohet me ndryshimin e regjistruar në të. Kur sheh ndryshime, ai mund të shtyjë dërgimin e kërkesës për ndërtim (të shtyhet për një periudhë të caktuar në parametrin e veçantë treeStableTimer ). Nëcaktosh emrin e planifikimit, i cili do të shfaqet në emri -interfacinë web. Në BuildBotChangeFilter caktosh filtrin, duke kaluar përmes të cilit ndryshimet në degë përshpejtojnë kërkesën e ndërtimit. Në builderNames specifikohet emri -a, i cili do të caktohet pak më vonë. Emri në rastin tonë do të jetë po ai si emri i projektit: builderyourProject ForceScheduler.
është një gjë mjaft e thjeshtë. Ky lloj planifikimi aktivizohet me një klik të mausit përmes -interfacinë web. Parametrat kanë të njëjtin qëllim si në BuildBotP.S. №3. Mund të jetë i dobishëm – një nga klasat më të njohura të planifikimit. Ai monitoron një degë dhe aktivizohet me ndryshimin e regjistruar në të. Kur sheh ndryshime, ai mund të shtyjë dërgimin e kërkesës për ndërtim (të shtyhet për një periudhë të caktuar në parametrin e veçantë.
Periodic
– është një planifikim që aktivizohet me një periudhë të caktuar që ndodh me rregull. Thirrja e tij duket kështu from buildbot.plugins import schedulers nightly = schedulers.Periodic(name="daily", builderNames=["full-solaris"], periodicBuildTimer=24*60*60) c['schedulers'] = [nightly]
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": "."}))
5.5 BuildFactory
periodicBuildTimer
cakon periudhën e dhehje në sekonda. BuildFactory
krijon konkretin , i cili më pas ndërtodërgon në builder specifikohen hapat që duhet të realizohen Punëtori. Në krijon konkretin -u. Hapat shtohen përmes thirrjes së metodës PunëtoriaddStep Hapi i parë i shtuar në këtë shembull është
git clean -d -f -f –x . Këto veprime janë parashikuar në parametrin, pastaj git checkout, i cili nuk është vizualisht i specifikuar, por nënkupton një vlerë parazgjedhjeje metodafresh mode='incremental'. Parametri tregon se skedarët nga direktoria, ku bëhet chechout , e cila nuk është e pranishme në depo, mbetet e paprekur.Hapi i dytë i shtuar është thirrja e skenarit
në anën trial me parametrin hello -a nga direktoria Punëtoric me variablin e mjedisit PATHONPATH=… Kështu, mund të shkruani skriptet tuaja dhe t'i ekzekutoni në anën /home/habr/worker/yourProject/build -a përmes hapit Punëtoriutil.ShellCommand . Këto skripta mund të vendosen drejtpërdrejt në depo. Atëherë gjatë-e ato do të shkojnë në , e cila nuk është e pranishme në depo, mbetet e paprekur.. Mirëpo, atëherë ka dy „po”: /home/habr/worker/yourProject/buildduhet të krijohet me çelësin
- Punëtori —umask -e këtyre skripteve, duhet të specifikohet pronësia checkout-a.
- Në git pushexacutable , që më vonë të mos humbase të drejtat për të ekzekutuar skriptin Git.c['builders'] = [] c['builders'].append(util.BuilderConfig(name="runtests", workernames=["example-worker"], factory=factory)) , e cila nuk është e pranishme në depo, mbetet e paprekur.Rreth asaj që është
5.6 ndërtuesit
u diskutua
. Tani do të flas më në detaje se si ta krijojmë atë. Builder BuilderConfig është konstruktor . Ka disa të tillë në c[‘builders’] buildermund të caktohen disa, sepse është një listë objektesh për tipo. Tani do ta përmirësojmë disi shembullin nga , duke e afruar atë me detyrën tonë. builder c['builders'] = [] c['builders'].append(util.BuilderConfig(name="yourProject", workernames=["yourWorkerName"], factory=factory)) BuildBotTani do të flas për parametrat
caktosh emrin
-a. Këtu e kemi quajtur . Ka disa të tillë në.
emri . Kjo do të thotë se mbi builder-e do të krijohet ky rrugë ForceSchedulergjendet Punëtoripërshtatet saktësisht me këtë emër. /home/habr/worker/yourProject/build. Scheduler workernames builder përmban një listë
-ësh. Secili prej tyre duhet të shtohet në c[‘workers’] Punëtorifactory – është konkret.
, me të cilin është i asocuar . Ai do të dërgojë objektin ndërtopër të realizuar të gjitha hapat që bëjnë pjesë në këtë builderKy është arhitektura e shembullit të projektit, që unë sugjeroj ta realizojmë përmes ndërto në Punëtori Si sistemin e kontrollit të versioneve, do të përdorim ndërto-a.
6. Shembulli i konfigurimit tonë
svn BuildBot
.
. Depoja do të ndodhet në një cloud të caktuar. Këtu është adresa e këtij cloud-it. svn. Repozitori do të jetë në një hapësirë të caktuar. Këtu është adresa e kësaj hapësire. . Në hapësirë ka një llogari username: svn , passwd: përdorues. Skriptet, që përbëjnë hapat password-a do të gjenden gjithashtu në degë ndërto, në një dosje të veçantë svnbuildbot/worker_linux . Këto skripte janë në repo me pronësinë e ruajturexecutable punojnë në një host të vetëm.
BuildMaster dhe Punëtori project.host ruan skedarët e tij në dosjen .BuildMaster ruan gjithashtu në rrugën e mëposhtme /home/habr/master. Punëtori . Komunikimi i proceseve /home/habr/worker-a dhe BuildMaster-a bëhet përmes portit 4000 me protokollin Punëtori-a, do thotë BuildBot'pb' protokol. Projekti i synuar është kompletuar plotësisht në python. Detyra është të ndjekë ndryshimet e tij, të krijojë një skedar ekzekutiv, të gjenerojë dokumentacionin, të kryejë testimin. Në rast dështimi, duhet të dërgohet një mesazh në email të gjithë zhvilluesve për veprimin e dështuar.
Pamja në Web
ne do ta lidhim në portin 80 për BuildBot . Apatch nuk është e nevojshme të instalohet. Brenda bibliotekës ruan skedarët e tij në dosjentwisted gjendet tashmë një server web, e cila përdoret. BuildBot Për ruajtjen e informacionit të destinuar për brendshëm për
Për dërgimin e email-eve, është nevojshme një host BuildBot do të përdorim sqlite.
smtp.your.domain — në të është e lejuar dërgimi i emaileve nga adresa projectHost@your.domain pa autentifikim. Po ashtu, në hostin ' smtp' protokolli dëgjohet në portin 1025. Persona të angazhuar në proces janë dy:
. admin administron admin dhe përdorues. user është personi që kryen BuildBot-a. commitSkedari Exacutable krijohet përmes
pyinstaller . Dokumentacioni krijohet përmesdoxygen Për këtë arkitekturë, kam shkruar këtë.
Fillimisht, është e nevojshme 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>Statusi i ndërtimit të çliruar: {{ summary }}</h4>
<p>Shërbimi i përdorur për ndërtimin: {{ workername }}</p>
<p>Projekti: {{ projects }}</p>
<p>Për të parë ndërfaqen e menaxhimit, ndiqni lidhjen: {{ buildbot_url }}</p>
<p>Për të parë rezultatin e ndërtimit, ndiqni lidhjen: {{ build_url }}</p>
<p>Duke përdorur WinSCP, mund të lidheni me serverin me ip:xxx.xx.xxx.xx. Duke u futur me habr/password, merrni skedarin ekzekutiv të ndërtuar nga direktoria ~/worker/yourProject/build/dist.</p>
<p><b>Ndërtimi u realizua nëpërmjet 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'] = "Procesi i ndërtimit"
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"
}
-a. Pastaj, të futet ky skedar BuildMaster-a bëhet përmes portit 4000 me protokollin PunëtoriHapi tjetër kërkon që të nisë shërbimin master.cfg në /home/habr/master.
sudo buildbot start /home/habr/master BuildMaster-a
Pastaj, të niset shërbimi
buildbot-worker start /home/habr/worker Punëtori-a
Gati! Tani
do të ndjekë ndryshimet dhe do të aktivizohet për Buildbot -a në commit, duke kryer hapat e ndërtimit dhe testimit të projektit me arkitekturën e përmendur më sipër. svnMë poshtë, do të përshkruaj disa veçori të
master.cfg. Gjatë shkrimit të tij
6.1 Në rrugën drejt master.cfg tonë
do të bëhen disa gabime, prandaj do të jetë e nevojshme të lexoni skedarin log. Ai ruhet si në master.cfg -e c me rrugën absolute BuildMaster, ashtu edhe në anën /home/habr/master/twistd.log-a me rrugën absolute Punëtori. Ndërsa lexoni gabimet dhe duke i korrigjuar ato, do të jetë e nevojshme të rifilloni shërbimin /home/habr/worker/twistd.log-a. Kështu bëhet: BuildMastersudo buildbot stop /home/habr/master sudo buildbot upgrade-master /home/habr/master sudo buildbot start /home/habr/master
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)
6.2 Puna me svn
Fillimisht, le të shohim
svn_poller . Ky është i njëjti ndërfaqe, që pyet rregullisht repositorin çdo minutë. Në këtë rasti qaset vetëm degës . Ky është i njëjti ndërfaqe, që pyet rregullisht repositorin çdo minutë. Në këtë rast . Parametri misterioz trunksplit_file=util.svn.split_file_alwaystrunk përcakton rregullat: se si të ndash strukturën e dosjeve në dega. Ai ofron gjithashtu këto rrugë relative. Nga ana tjetër svn split_file_alwaystrunk e thjeshton procesin, duke thënë se në repo ekziston vetëm Schedulers trunk.
Në , që e sheh shkruhet caktosh filtrin, duke kaluar përmes të cilit ndryshimet në degë përshpejtojnë kërkesën e ndërtimit. Nësipërm të dhënë në lidhje përmes Asnjë . Reagon në ndryshimet në trunk , aktivizon e thjeshton procesin, duke thënë se në repo ekziston vetëmc me emrin trunkkëtu është e nevojshme që admin të marrë informacion në lidhje me rezultatet e ndërtimit dhe testimit si pronari i procesit. builder i aftë për të bërë një fshirje të plotë të të gjitha skedarëve, që ndodhen në versionin lokal të repo ForceScheduler.
propertietet -a. Pastaj, të bëjë një të plotë
Hapi ndërto-a checkout svn update Punëtori. Moda është e konfiguruar përmes parametrave mode=fullmethod=fresh haltOnTailure, tregon se nëse. Parametri kryhet me një gabim, pastaj i gjithë procesi i ndërtimit dhe testimit duhet të pezullohet, pasi veprimet e mëtejshme nuk kanë kuptim. reporters mode=full — është shërbimi i dërgimit të njoftimeve në email.
6.3 Ju dërgohet një email: reporterët janë të autorizuar të deklarojnë
Ai mund të dërgojë mesazhe në mënyra të ndryshme
template_html=u'''
<h4>Statusi i ndërtimit të çliruar: {{ summary }}</h4>
<p>Shërbimi i përdorur për ndërtimin: {{ workername }}</p>
<p>Projekti: {{ projects }}</p>
<p>Për të parë ndërfaqen e menaxhimit, ndiqni lidhjen: {{ buildbot_url }}</p>
<p>Për të parë rezultatin e ndërtimit, ndiqni lidhjen: {{ build_url }}</p>
<p>Duke përdorur WinSCP, mund të lidheni me serverin me ip:xxx.xx.xxx.xx. Duke u futur me habr/password, merrni skedarin ekzekutiv të ndërtuar nga direktoria ~/worker/yourProject/build/dist.</p>
<p><b>Ndërtimi u realizua nëpërmjet 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]
MailNotifier .
template_html përcakton modelin e tekstit për dërgimin. Për krijimin e markupit përdoret html. Ai është modifikuar nga engine
(mund të krahasohet me django ka një set variablesh, vlerat e të cilave vendosen në model gjatë krijimit të mesazhit. Këto variabla janë shkruar në {{ kllapa të dyfishta }}. Pra, për shembull, tregon statusin e operacioneve të kryera, domethënë success ose failure. Ndërsa). BuildBot projects përmbledhja do të tregojë . Kështu, me ndihmën e komandave kontrolluese në , variablave ForceScheduler-a dhe mjeteve të formatimit të vargjeve python, mund të krijohet një mesazh mjaft informues. jinja2përmban argumente të mëposhtme. BuildBotfromaddr
template_html – adresa nga e cila do të dërgohen njoftimet.
sendToInterestedUsers =True dërgon mesazhin pronarit dhe përdoruesit që bëri
lookup=True отсылает сообщение владельцу и пользователю, который сделал commit.
lookup — sufiksi që duhet të shtohet në emrat e përdoruesve që marrin njoftime. Kështu admin si përdoruesi do të marrë një mesazh në adresën admin@your.domain.
relayhost caktuar emrin e hostit ku është hapur serveri ' protokolli dëgjohet në portin 1025., a smptPort caktuar numrin e portit që dëgjon ' protokolli dëgjohet në portin 1025. server.
mode=«warning» thotë se duhet të dërgohet një mesazh vetëm në rast se ka të paktën një hap ndërto-a që ka përfunduar me statusin dështim ose paralajmërim. Në rastin e suksesit, nuk kërkohet dërgimi i mesazhit.
extraRecipients përmban një listë personash, të cilëve duhet t'u dërgohet mesazhi përveç pronarit dhe personit që e ka realizuar commit.
messageFormatter është një objekt që cakton formatin e mesazhit, modelin e tij dhe grupin e variableve të disponueshme nga jinja2. Parametra të tillë si wantProperties=True dhe wantSteps=True caktuar këtë grup të variableve të disponueshme.
s[‘services’]=[sendMessageToAll] siguron një listë shërbimesh, përfshirë tonën reporter.
E bëmë! Urime
Krijuam një konfigurim të vetin dhe pamë funksionalitetin që mund të ofrojë BuildBot. Mendoj se ky është mjaftueshëm për të kuptuar nëse ky mjet është i nevojshëm për krijimin e projektit tuaj. A ju intereson? A do t'ju nevojitet? A është e lehtë të punoni me të? Atëherë nuk e shkruaj këtë artikull për kot.
Dhe diçka tjetër. Do të dëshiroja që komuniteti profesionist që përdor BuildBot, të bëhet më i gjerë, manualet të përktheheshin dhe të kishte më shumë shembuj.
Të gjithë faleminderit për vëmendjen. Fat të mbarë.
Burimi: habr.com
