(Bildo de el
Saluton!
Mia nomo estas Evgenij Ĉerkin, Mi estas programisto en evolua teamo ĉe minindustria kompanio Polimetalo.
Komencante ajnan grandan projekton, vi komencas pensi: "Kiu programaro estas plej bona uzi por konservi ĝin?" IT-projekto trairas kelkajn stadiojn antaŭ publikigo de la sekva versio. Estas bone kiam la ĉeno de ĉi tiuj etapoj estas aŭtomatigita. La aŭtomatigita procezo liberigi novan version de IT-projekto mem nomiĝas Kontinua Integriĝo. BuildBot montriĝis bona asistanto por ni en efektivigo de ĉi tiu procezo.
En ĉi tiu artikolo mi decidis doni superrigardon de la eblecoj BuildBot. Kion kapablas ĉi tiu programaro? Kiel alproksimiĝi al li kaj kiel konstrui kun li normalan EFIKAN LABORRILATOJ? Vi povas apliki nian sperton mem kreante funkciantan servon por konstrui kaj testi vian projekton sur via maŝino.
Enhavo
Enhavo
1. Kial BuildBot?
Antaŭe ĉe habr-e mi renkontis artikolojn pri efektivigo Kontinua Integriĝo uzante BuildBot. Ekzemple, Mi trovis ĝin la plej informa. Estas alia ekzemplo - . Ĉi tiuj artikoloj povas esti spicitaj kaj post tio, en la angla. La coupé estas bona deirpunkto. Post legado de ĉi tiuj artikoloj, vi verŝajne tuj deziros ion BuildBot fari.
Ĉesu! Ĉu iu efektive uzis ĝin en siaj projektoj? Rezultas ke jes aplikis ĝin en siaj taskoj. Troveblas uzo de BuildBot kaj en Guglo-kodaj arkivoj.
Kio do estas la logiko de homoj uzantaj Buildbot? Post ĉio, ekzistas aliaj iloj: Krozkontrolo и Jenkins. Mi respondos tiel. Por plej multaj taskoj Jenkins kaj la vero sufiĉos. Siavice, BuildBot - pli adapta, dum problemoj estas solvitaj tie same simple kiel en Jenkins. La elekto estas via. Sed ĉar ni serĉas ilon por evoluiga celprojekto, kial ne elekti unu, kiu permesos, ekde simplaj paŝoj, akiri konstruan sistemon, kiu havas interagadon kaj unikan interfacon.
Por tiuj, kies celprojekto estas skribita en python, la demando ekestas: "Kial ne elekti integrigan sistemon kiu havas klaran interfacon laŭ la lingvo uzata en la projekto?" Kaj nun estas tempo prezenti la avantaĝojn BuildBot.
Do, nia "instrumenta kvarteto". Por mi mem, mi identigis kvar trajtojn BuildBot:
- Ĝi estas malfermkoda kadro sub GPL-licenco
- Ĉi tio estas la uzo de python kiel agorda ilo kaj priskribo de la postulataj agoj
- Ĉi tio estas ŝanco ricevi respondon de la maŝino, sur kiu okazas la asembleo
- Ĉi tiuj estas, finfine, la minimumaj postuloj por Gastiganto. Deplojo postulas python kaj tordita, kaj ne postulas virtualan maŝinon kaj java maŝino.
2. Koncepto gvidata de BuildMaster
Centra al la taska distribua arkitekturo estas BuildMaster. Ĝi estas servo kiu:
- sekvas spuron ŝanĝoj en la projekta fontarbo
- sendas komandoj, kiuj devus esti ekzekutitaj de la Laboristo-servo por konstrui la projekton kaj testi ĝin
- sciigas uzantoj pri la rezultoj de agoj faritaj
BuildMaster agordita per dosiero majstro.cfg. Ĉi tiu dosiero estas en la radiko BuildMaster. Poste mi montros kiel ĉi tiu radiko estas kreita. La dosiero mem majstro.cfg enhavas python-skripton, kiu uzas vokojn BuildBot.
Sekva plej grava objekto BuildBot havas nomon Laboristo. Ĉi tiu servo povas esti lanĉita sur alia gastiganto kun malsama OS, aŭ eble sur tiu kie BuildMaster. Ĝi ankaŭ povas ekzisti en speciale preta virtuala medio kun siaj propraj pakaĵoj kaj variabloj. Ĉi tiuj virtualaj medioj povas esti preparitaj uzante python-servaĵojn kiel virtualenv, venv.
BuildMaster elsendas ordonojn al ĉiuj Laboristo-y, kaj li, siavice, plenumas ilin. Tio estas, ĝi rezultas, ke la procezo de konstruado kaj testado de projekto povas daŭri Laboristo-e kurante Vindozon kaj sur alia Laboristo kurante Linukso.
Checkout projektaj fontkodoj okazas sur ĉiu Laboristo-e.
3. Instalado
Do, ni iru. Mi uzos Ubuntu 18.04 kiel la gastiganto. Mi metos unu sur ĝin BuildMaster-a kaj unu Laboristo-a. Sed unue vi devas instali python3.7:
sudo apt-get update
sudo apt-get install python3.7
Por tiuj, kiuj bezonas python3.7.2 anstataŭ 3.7.1, vi povas fari la jenon:
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
La sekva paŝo estas instali Tweitita и BuildBot, same kiel pakaĵojn, kiuj ebligas al vi uzi aldonan funkcion BuildBot-La.
/*Все что под 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. Unuaj paŝoj
Tempo por krei BuildMaster. Ĝi estos en nia dosierujo /home/habr/master.
mkdir master
buildbot create-master master # Собственно сдесь и создаемSekva paŝo. Ni kreu Laboristo. Ĝi estos en nia dosierujo /home/habr/laboristo.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Kiam vi kuras Laboristo, tiam defaŭlte ĝi kreos en /home/habr/laboristo dosierujo kun la nomo de la projekto, kiu estas specifita en majstro.cfg. Kaj en la dosierujo kun la nomo de la projekto ĝi kreos dosierujon konstruu, kaj daŭre faros ĝin kaso. Labora dosierujo por Laboristo-kaj ĝi fariĝos dosierujo /home/habr/yourProject/build.
"Ora Ŝlosilo
Kaj nun por kio mi skribis la antaŭan alineon: skripto tio majstro postulos de Laboristo-kaj farita malproksime en ĉi tiu dosierujo ne estos ekzekutita ĉar la skripto ne havas la rajtojn ruliĝi. Por korekti la situacion, vi bezonos ŝlosilon --umask=0o22, kiu malpermesas skribi al ĉi tiu dosierujo, sed konservos lanĉrajtojn. Kaj tio estas ĉio, kion ni bezonas.
BuildMaster и Laboristo establi ligon unu kun la alia. Okazas ke ĝi rompas kaj Laboristo atendante iom da tempo respondon de BuildMaster-A. Se ne estas respondo, la konekto estas rekomencita. Ŝlosilo --keepalive=60 nur bezonis indiki la tempon post kiu konekti rekomencas.
5. Agordo. Paŝo post paŝo recepto
Agordo BuildMaster estas efektivigita sur la flanko de la maŝino kie ni ekzekutis la komandon krei-majstro. En nia kazo, ĉi tio estas dosierujo /home/habr/master. Agorda dosiero majstro.cfg ankoraŭ ne ekzistas, sed la komando mem jam kreis la dosieron majstro.cmg.specimeno. Vi devas renomi ĝin al majstro.cfg.specimeno в majstro.cfg
mv master.cfg.sample master.cfgNi malfermu ĉi tiun majstro.cfg. Kaj ni rigardu el kio ĝi konsistas. Kaj post tio, ni provu fari nian propran agordan dosieron.
majstro.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 — baza vortaro de la agorda dosiero. Ĝi devas esti inkluzivita en la agorda dosiero. Por facileco de uzo, kaŝnomo estas enkondukita en la agorda kodo "c". Titoloj в c["keyFromDist"] estas fiksaj elementoj por interagado kun BuildMaster. Por ĉiu ŝlosilo, la responda objekto estas anstataŭigita kiel valoro.
5.2-laboristoj
c['workers'] = [worker.Worker("example-worker", "pass")]Ĉi-foje ni indikas BuildMaster-y listo de Laboristo-s. Mi mem Laboristo ni kreis , indikante vi-laboristo-nomo и pasvorto. Nun ili devas esti precizigitaj anstataŭe ekzemplo-laboristo и pasas .
5.3 ŝanĝi_fonto
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
Per ŝlosilo ŝanĝi_fonto vortaro c ni ricevas aliron al la listo, kie ni volas meti objekton, kiu sondas la deponejon kun la fontkodo de la projekto. La ekzemplo uzas Git-deponejon, kiu estas balotita je certaj intervaloj.
La unua argumento estas la vojo al via deponejo.
workdir reprezentas la vojon al la dosierujo kie sur la flanko Laboristo-a relative al la vojo /home/habr/worker/yourProject/build git stokos la lokan version de la deponejo.
branĉo enhavas specifan branĉon en la deponejo, kiun oni devas sekvi.
pollInterval enhavas la nombron da sekundoj post kiuj BuildMaster elektos la deponejon por ŝanĝoj.
Estas pluraj metodoj por spuri ŝanĝojn al la deponejo de projekto.
La plej simpla metodo estas Enketo, kio implicas tion BuildMaster periode sondas la servilon kun la deponejo. Se fari reflektis la ŝanĝojn en la deponejo, do BuildMaster kreos internan objekton kun iom da prokrasto ŝanĝo kaj sendu ĝin al la eventa prizorganto Planisto, kiu lanĉos la paŝojn por konstrui kaj testi la projekton Laboristo-e. Inter ĉi tiuj paŝoj estos indikitaj ĝisdatigo deponejo. Ĝuste sur LaboristoĈi tio kreos lokan kopion de la deponejo. La detaloj de ĉi tiu procezo estos kovritaj sube en la sekvaj du sekcioj. ( и ).
Eĉ pli eleganta metodo por spuri ŝanĝojn al deponejo estas sendi mesaĝojn rekte de la servilo gastiganta ĝin al BuildMaster- pri ŝanĝado de la projektaj fontkodoj. En ĉi tiu kazo, tuj kiam la programisto faras fari, la servilo kun la projekta deponejo sendos mesaĝon BuildMaster-y. Kaj li siavice kaptos ĝin kreante objekton PBChageSource. Poste, ĉi tiu objekto estos transdonita al Planisto, kiu aktivigas la paŝojn por konstrui la projekton kaj testi ĝin. Grava parto de ĉi tiu metodo estas labori kun fiŝhoko-servilaj skriptoj en la deponejo. En la skripto fiŝhoko-a, respondeca pri prilaborado de agoj kiam fari-e, vi devas voki la ilon sendiŝanĝon kaj specifu la retadreson BuildMaster-A. Vi ankaŭ devas specifi la retan havenon, kiu aŭskultos PBChageSource. PBChageSource, cetere, estas parto BuildMaster-A. Ĉi tiu metodo postulos permeson administristo-a sur la servilo kie troviĝas la projekta deponejo. Vi unue devos fari sekurkopion de la deponejo.
5.4 planistoj
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"]))
horaroj – ĉi tio estas elemento, kiu funkcias kiel ellasilo, kiu komencas la tutan ĉenon de muntado kaj testado de la projekto.
Tiuj ŝanĝoj kiuj estis registritaj ŝanĝi_fonto, transformita en la procezo de laboro BuildBot-a oponi ŝanĝo kaj nun ĉiu Sheduler surbaze de ili, ĝi konstruas petojn por komenci la projektan konstruprocezon. Tamen, ĝi ankaŭ determinas kiam ĉi tiuj petoj estas transdonitaj plu al la atendovico. Objekto konstruisto stokas vicon da petoj kaj spuras la staton de la nuna asembleo sur aparta Laboristo-e. konstruisto ekzistas sur BuildMaster-e kaj plu Laboristo-e. Li sendas kun BuildMaster-a on Laboristo-kaj jam specifa konstruu - serio da paŝoj, kiujn oni devas sekvi.
Ni vidas ke en la nuna ekzemplo tia horaroj 2 pecoj estas kreitaj. Krome, ĉiu havas sian propran tipon.
SingleBranchScheduler - unu el la plej popularaj klasoj en la horaro. Ĝi observas unu branĉon kaj estas ekigita de registrita ŝanĝo en ĝi. Kiam li vidas ŝanĝojn, li povas prokrasti sendi la konstrupeton (prokrasti por la periodo specifita en la speciala parametro treeStableTimer). EN nomo fiksas la nomon de la horaro, kiu estos montrata BuildBot-retinterfaco. EN Ŝanĝi Filtrilon filtrilo estas starigita, post pasi kiuj ŝanĝoj en la branĉo instigas la horaron sendi peton por konstruado. EN builderNames nomo estas indikita konstruisto-a, kiun ni starigos iom poste. La nomo en nia kazo estos la sama kiel la nomo de la projekto: via Projekto.
ForceScheduler tre simpla afero. Ĉi tiu tipo de horaro estas ekigita per musklako BuildBot-retinterfaco. La parametroj havas la saman esencon kiel en SingleBranchScheduler.
PS n-ro 3. Eble ĝi utilos
Perioda estas horaro, kiu funkcias je certa tempofiksita frekvenco. La voko aspektas kiel ĉi tio
from buildbot.plugins import schedulers
nightly = schedulers.Periodic(name="daily",
builderNames=["full-solaris"],
periodicBuildTimer=24*60*60)
c['schedulers'] = [nightly]
5.5 Konstrufabriko
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": "."}))
periodBuildTimer specifas la tempon de tiu periodeco en sekundoj.
BuildFactory kreas specifan konstruu, kiu tiam konstruisto sendas al Laboristo. la BuildFactory indikas la paŝojn por esti sekvitaj Laboristo-y. Paŝoj estas aldonitaj per vokado de la metodo aldoni Paŝon
La unua aldonita paŝo en ĉi tiu ekzemplo estas git pura -d -f -f –xtiam git kaso. Ĉi tiuj agoj estas inkluzivitaj en la parametro metodo, kiu ne estas klare dirita sed implicas defaŭltan valoron freŝa... Parametro reĝimo = 'pliiga' indikas ke la dosieroj estas de la dosierujo kie la chechout, dum mankas el la deponejo, restas netuŝita.
La dua aldonita paŝo estas voki la skripton juĝo kun parametro saluton flanke Laboristo-a el dosierujo /home/habr/worker/yourProject/build kun la mediovariablo PATHONPATH=... Tiel, vi povas skribi viajn proprajn skriptojn kaj efektivigi ilin flanke. Laboristo-a ĉiu paŝo util.ShellCommand. Ĉi tiuj skriptoj povas esti metitaj rekte en la deponejon. Tiam je chechout-e ili falos en /home/habr/worker/yourProject/build. Tamen, tiam estas du "sed":
- Laboristo devas esti kreita per ŝlosilo por ke ĝi ne bloku ekzekutrajtojn post kaso-La.
- ĉe git push-e el ĉi tiuj skriptoj vi devas specifi la posedaĵon ekzakteblapor ke poste chechout-e ne perdis la rajton ekzekuti la Git-skripton.
5.6 konstruistoj
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Pri kio estas konstruisto estis rakontita . Nun mi rakontos al vi pli detale pri kiel krei ĝin. BuilderConfig estas konstrukciisto konstruisto. Tiaj dizajnistoj en c['konstruistoj'] vi povas specifi plurajn, ĉar ĉi tio estas folio de objektoj konstruisto tajpu. Nun ni reverku la ekzemplon de BuildBot, proksimigante ĝin al nia tasko.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Nun mi rakontos al vi pri la parametroj BuilderConfig.
nomo specifas la nomon konstruisto-a. Ĉi tie ni nomis ĝin via Projekto... Ĉi tio signifas, ke sur Laboristo— ĝuste ĉi tiu vojo estos kreita /home/habr/worker/yourProject/build. Sheduler serĉas konstruisto nur per ĉi tiu nomo.
labornomoj enhavas folion Laboristo-s. Ĉiu el kiuj devas esti aldonita al c ['laboristoj'].
fabriko - specifa konstruu, kun kiu ĝi estas rilata konstruisto. Li sendos la objekton konstruu sur Laboristo plenumi ĉiujn paŝojn inkluzivitajn en ĉi tio konstruu-La.
6. Ekzemplo de via propra agordo
Jen la ekzempla projektarkitekturo, kiun mi proponas efektivigi per BuildBot
.
Ni uzos kiel sistemon de kontrolo de versio svn. La deponejo mem troviĝos en ia nubo. Jen la adreso de ĉi tiu nubo . En la nubo sube svn estas uzantnomo de konto: surhavi, passwd: pasvorto. Skriptoj kiuj reprezentas paŝojn konstruu-a ankaŭ estos en la branĉo svn, en aparta dosierujo buildbot/worker_linux. Ĉi tiuj skriptoj troviĝas en la deponejo kun la konservita posedaĵo plenumebla.
BuildMaster и Laboristo kuri sur la sama gastiganto projekto.gastiganto .BuildMaster konservas ĝiajn dosierojn en dosierujo /home/habr/master. Laboristo ĝi estas konservita en la sekva vojo /home/habr/laboristo. Proceza komunikado BuildMaster-a kaj Laboristo-a estas efektivigita per haveno 4000 laŭ la protokolo BuildBot-a, tio estas 'pb' protokolo.
La celprojekto estas skribita tute en Python. La tasko estas spuri ĝiajn ŝanĝojn, krei plenumeblan dosieron, generi dokumentadon kaj fari testadon. En kazo de malsukceso, ĉiuj programistoj devas sendi mesaĝon retpoŝte deklarante, ke estas malsukcesa ago.
TTT-ekrano BuildBot ni konektos al haveno 80 por projekto.gastiganto. Ne necesas instali Apatch. Kiel parto de la biblioteko plektita jam ekzistas retservilo, BuildBot uzas ĝin.
Stoki internajn informojn por BuildBot ni uzos sqlite.
Gastiganto estas postulata por sendi smtp.via.domajno - ĝi permesas sendi leterojn el poŝto [retpoŝte protektita] sen aŭtentigo. Ankaŭ sur la gastiganto 'SMTP ' La protokolo estas aŭdita ĉe poŝto 1025.
Estas du homoj implikitaj en la procezo: administristo и surhavi. administranto administras BuildBot. uzanto estas la persono faranta fari-s.
Ekzekutebla dosiero estas generita per pyinstaller. Dokumentado estas generita per doksigeno.
Por ĉi tiu arkitekturo mi skribis ĉi tion: majstro.cfg:
majstro.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>Статус построенного релиза: {{ 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="[email protected]",
sendToInterestedUsers=True,
lookup="your.domain",
relayhost="smtp.your.domain",
smtpPort=1025,
mode="warnings",
extraRecipients=['[email protected]'],
messageFormatter=reporters.MessageFormatter(
template=template_html,
template_type='html',
wantProperties=True,
wantSteps=True)
)
c['services'] = [sendMessageToAll]
c['title'] = "The process of bulding"
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"
}
Unue vi bezonas BuildMaster-a kaj Laboristo-a. Poste algluu ĉi tiun dosieron majstro.cfg в /home/habr/master.
La sekva paŝo estas komenci la servon BuildMastera
sudo buildbot start /home/habr/master
Poste komencu la servon Laboristo-a
buildbot-worker start /home/habr/worker
Preta! Nun Buildbot spuros ŝanĝojn kaj ellasos fari-y en svn, plenumante la paŝojn de konstruado kaj testado de projekto kun ĉi-supra arkitekturo.
Malsupre mi priskribos kelkajn trajtojn de la supre majstro.cfg.
6.1 Survoje al via majstro.cfg
Skribante mian majstro.cfg Multaj eraroj estos faritaj, do necesas legi la protokoldosieron. Ĝi estas konservita kiel BuildMaster-ec absoluta vojo /home/habr/master/twistd.log, kaj flanke Laboristo-a kun absoluta vojo /home/habr/worker/twistd.log. Dum vi legas la eraron kaj riparas ĝin, vi devos rekomenci la servon BuildMaster-a. Jen kiel ĝi estas farita:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Laborante kun 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)
Unue, ni rigardu svn_poller. Ĉi tio ankoraŭ estas la sama interfaco, regule sondante la deponejon unufoje ĉiuminute. Tiuokaze svn_poller nur aliras la branĉon trunko. Mistera parametro split_file=util.svn.split_file_alwaystrunk fiksas la regulojn: kiel rompi la dosierujon svn sur la branĉoj. Li ankaŭ proponas al ili relativajn vojojn. Siavice split_file_alwaystrank simpligas la procezon dirante ke la deponejo nur enhavas trunko.
В Planistoj indikita Ŝanĝi Filtrilonkiu vidas neniu kaj asocias branĉon kun ĝi trunko laŭ donita asocio tra split_file_alwaystrank. Respondante al ŝanĝoj en trunko, Lanĉoj konstruisto kun nomo via Projekto.
proprietoj ĉi tie necesas por ke la administranto ricevu dissendolistojn de konstruaj kaj testaj rezultoj kiel posedanto de la procezo.
Paŝo konstruu-a kaso kapabla tute forigi ajnajn dosierojn situantajn en la loka versio de la deponejo Laboristo-A. Kaj tiam faru la plenan svn-ĝisdatigo. La reĝimo estas agordita per la parametro mode=plena, metodo=freŝa... Parametro haltOnTailure diras ke se svn-ĝisdatigo estos efektivigita kun eraro, tiam la tuta procezo de konstruado kaj testado devas esti suspendita, ĉar pliaj agoj ne havas sencon.
6.3 Letero al vi: raportistoj rajtas deklari
raportistoj estas servo por sendi sciigojn retpoŝte.
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="[email protected]",
sendToInterestedUsers=True,
lookup="your.domain",
relayhost="smtp.your.domain",
smtpPort=1025,
mode="warnings",
extraRecipients=['[email protected]'],
messageFormatter=reporters.MessageFormatter(
template=template_html,
template_type='html',
wantProperties=True,
wantSteps=True)
)
c['services'] = [sendMessageToAll]
Li povas sendi mesaĝojn .
MailNotifier uzas retpoŝton por sendi sciigojn.
ŝablono_html fiksas la tekstan ŝablonon por la informilo. HTML estas uzata por krei markadon. Ĝi estas modifita de la motoro (povas esti komparebla kun django). BuildBot havas aron da variabloj, kies valoroj estas anstataŭigitaj en la ŝablonon dum la procezo de generado de la mesaĝa teksto. Ĉi tiuj variabloj estas enfermitaj en {{ duoblaj buklaj krampoj }}. Ekzemple, resumo montras la staton de finitaj operacioj, tio estas, sukceso aŭ malsukceso. A projektoj eligos via Projekto. Do, uzante kontrolkomandojn en jinja2, variabloj BuildBot-a kaj python-ĉenformataj iloj, vi povas krei sufiĉe informan mesaĝon.
MailNotifier enhavas la jenajn argumentojn.
fromaddr – la adreso de kiu ĉiuj ricevos la informilon.
sendiAlInteresitaj Uzantoj=True sendas mesaĝon al la posedanto kaj uzanto kiu faris fari.
serĉo — sufikso, kiu devas esti aldonita al la nomoj de uzantoj ricevantaj la bultenon. Do administristo kiel la uzanto ricevos la bultenon ĉe la adreso [retpoŝte protektita].
relayhost specifas la gastigan nomon sur kiu la servilo estas malfermita SMTP, a smptPort specifas la havennumero kiu aŭskultas SMTP servilo.
modo = "averto" diras ke la dissendo estu farita nur se estas almenaŭ unu paŝo konstruu-a, kiu finiĝis per la statusa fiasko aŭ averto. Okaze de sukceso, ne necesas sendi bultenon.
ekstraricevantoj enhavas liston de personoj al kiuj la poŝto devus esti sendita krom la posedanto kaj la persono kiu efektivigis la fari.
mesaĝformato estas objekto, kiu precizigas la mesaĝformaton, ĝian ŝablonon kaj aron de variabloj disponeblaj de jinja2. Opcioj kiel ekzemple wantProperties=Vera и wantSteps=Vere difinu ĉi tiun aron de disponeblaj variabloj.
with['services']=[sendMessageToAll] provizas liston de servoj, inter kiuj la nia estos raportisto.
Ni faris ĝin! Gratulon
Ni kreis nian propran agordon kaj vidis la funkciojn, kiujn ĝi kapablas. BuildBot. Ĉi tio, mi pensas, sufiĉas por kompreni ĉu ĉi tiu ilo estas necesa por krei vian projekton. Ĉu vi interesiĝas pri li? Ĉu ĝi estos utila al vi? Ĉu li estas komforta labori kun li? Tiam mi ne vane skribas ĉi tiun artikolon.
Kaj plu. Mi ŝatus ke la profesia komunumo uzu BuildBot, iĝis pli larĝa, manlibroj estis tradukitaj, kaj ekzistis eĉ pli da ekzemploj.
Dankon al vi ĉiuj pro via atento. Bonŝancon.
fonto: www.habr.com