(Imatge de de
Hi!
el meu nom Evgeniy Cherkin, sóc programador d'un equip de desenvolupament d'una empresa minera Polimetal.
Quan inicieu un projecte gran, comenceu a pensar: "Quin programari és millor utilitzar per donar-hi servei?" Un projecte informàtic passa per diverses etapes abans de llançar la següent versió. És bo quan la cadena d'aquestes etapes està automatitzada. S'anomena el procés automatitzat de llançament d'una nova versió d'un projecte informàtic Integració contínua. BuildBot va resultar ser un bon assistent per a nosaltres en la implementació d'aquest procés.
En aquest article he decidit oferir una visió general de les possibilitats BuildBot. De què és capaç aquest programari? Com apropar-se a ell i com construir amb ell una RELACIÓ DE LABOR EFECTIVA normal? Pots aplicar tu mateix la nostra experiència creant un servei de treball per construir i provar el teu projecte a la teva màquina.
Contingut
Contingut
1. Per què BuildBot?
Anteriorment a habr-e vaig trobar articles sobre la implementació Integració contínua utilitzant BuildBot. Per exemple, Vaig trobar el més informatiu. Hi ha un altre exemple - . Aquests articles es poden condimentar I després, en anglès. El coupé és un bon punt de partida. Després de llegir aquests articles, probablement voldreu alguna cosa immediatament BuildBot fer.
Atura! Algú l'ha utilitzat realment en els seus projectes? Resulta que sí l'han aplicat en les seves tasques. Es pot trobar utilitzar BuildBot i als arxius de codi de Google.
Aleshores, quina és la lògica de l'ús de la gent Buildbot? Després de tot, hi ha altres eines: Control de creuer и Jenkins. Et respondré d'aquesta manera. Per a la majoria de tasques Jenkins i la veritat serà suficient. Al seu torn, BuildBot - més adaptatiu, mentre que els problemes es resolen amb la mateixa senzillesa com en Jenkins. L'elecció és vostra. Però com que estem buscant una eina per a un projecte objectiu en desenvolupament, per què no triar-ne una que permeti, a partir de passos senzills, obtenir un sistema de construcció que tingui interactivitat i una interfície única.
Per a aquells el projecte objectiu dels quals està escrit en python, sorgeix la pregunta: "Per què no escolliu un sistema d'integració que tingui una interfície clara pel que fa al llenguatge utilitzat en el projecte?" I ara és el moment de presentar els beneficis BuildBot.
Així doncs, el nostre “quartet instrumental”. Per a mi, he identificat quatre característiques BuildBot:
- És un marc de codi obert sota llicència GPL
- Aquest és l'ús de Python com a eina de configuració i descripció de les accions necessàries
- Aquesta és una oportunitat per rebre una resposta de la màquina en què es fa el muntatge
- Aquests són, finalment, els requisits mínims per a un Host. El desplegament requereix python i twisted, i no requereix una màquina virtual ni una màquina java.
2. Concepte liderat per BuildMaster
El centre de l'arquitectura de distribució de tasques és BuildMaster. És un servei que:
- fa un seguiment canvis a l'arbre font del projecte
- envia ordres que hauria d'executar el servei Worker per crear el projecte i provar-lo
- notifica usuaris sobre els resultats de les accions realitzades
BuildMaster configurat mitjançant un fitxer mestre.cfg. Aquest fitxer es troba a l'arrel BuildMaster. Més endavant mostraré com es crea aquesta arrel. El fitxer en si mestre.cfg conté un script Python que utilitza trucades BuildBot.
El següent objecte més important BuildBot Té el nom Obrer. Aquest servei es pot llançar en un altre amfitrió amb un sistema operatiu diferent, o potser en aquell on BuildMaster. També pot existir en un entorn virtual especialment preparat amb els seus propis paquets i variables. Aquests entorns virtuals es poden preparar mitjançant utilitats Python com virtualenv, venv.
BuildMaster transmet ordres a tothom Obrer-i, i ell, al seu torn, les compleix. És a dir, resulta que el procés de construcció i prova d'un projecte pot continuar Obrer-e amb Windows i en un altre Worker amb Linux.
Pagament els codis font del projecte es produeixen a cadascun Obrer-e.
3. Instal·lació
Així doncs, anem. Faré servir Ubuntu 18.04 com a amfitrió. En posaré un BuildMaster-a i una Obrer-a. Però primer heu d'instal·lar python3.7:
sudo apt-get update
sudo apt-get install python3.7
Per a aquells que necessiten python3.7.2 en lloc de 3.7.1, podeu fer el següent:
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
El següent pas és instal·lar Tuitejat и BuildBot, així com paquets que us permeten utilitzar funcionalitats addicionals BuildBot-El.
/*Все что под 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. Primers passos
Temps de crear BuildMaster. Estarà a la nostra carpeta /home/habr/master.
mkdir master
buildbot create-master master # Собственно сдесь и создаемSegüent pas. Anem a crear Obrer. Estarà a la nostra carpeta /home/habr/treballador.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Quan corres Obrer, llavors per defecte es crearà a /home/habr/treballador carpeta amb el nom del projecte, que s'especifica a mestre.cfg. I a la carpeta amb el nom del projecte crearà un directori construir, i ho seguirà fent caixa. Directori de treball per Obrer-i es convertirà en un directori /home/habr/yourProject/build.
"Clau d'or
I ara per al que vaig escriure el paràgraf anterior: un guió que Mestre exigirà de Obrer-i fet de forma remota en aquest directori no s'executarà perquè l'script no té permisos per executar-se. Per corregir la situació, necessitareu una clau --umask=0o22, que prohibeix escriure en aquest directori, però conservarà els drets de llançament. I això és tot el que necessitem.
BuildMaster и Obrer establir una connexió entre ells. Passa que es trenca i Obrer esperant durant un temps una resposta de BuildMaster-A. Si no hi ha resposta, es reinicia la connexió. clau --keepalive=60 només calia indicar el temps després del qual connectar reinicia.
5. Configuració. Recepta pas a pas
Configuració BuildMaster es realitza al costat de la màquina on hem executat l'ordre crear-mestre. En el nostre cas, aquest és un directori /home/habr/master. Fitxer de configuració mestre.cfg encara no existeix, però l'ordre ja ha creat el fitxer master.cmg.sample. Heu de canviar el nom a master.cfg.sample в mestre.cfg
mv master.cfg.sample master.cfgObrim aquest mestre.cfg. I mirem en què consisteix. I després d'això, intentem fer el nostre propi fitxer de configuració.
mestre.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 — diccionari bàsic del fitxer de configuració. S'ha d'incloure al fitxer de configuració. Per facilitar-ne l'ús, s'introdueix un àlies al codi de configuració "c". Títols в c["keyFromDist"] són elements fixos per a la interacció amb BuildMaster. Per a cada clau, l'objecte corresponent se substitueix com a valor.
treballadors 5.2
c['workers'] = [worker.Worker("example-worker", "pass")]Aquesta vegada us indiquem BuildMaster-y llista de Obrer-s. jo mateix Obrer vam crear , indicant nom-tu-treballador и contrasenya. Ara cal especificar-los exemple-treballador и passar .
5.3 canvi_font
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
Per clau canvi_font diccionari c tenim accés a la llista on volem posar un objecte que sondeja el repositori amb el codi font del projecte. L'exemple utilitza un repositori Git que s'enquesta a determinats intervals.
El primer argument és el camí al vostre repositori.
workdir representa el camí a la carpeta on es troba al costat Obrer-a relativa al camí /home/habr/worker/yourProject/build git emmagatzemarà la versió local del dipòsit.
branca conté una branca específica al repositori que s'ha de seguir.
pollInterval conté el nombre de segons després dels quals BuildMaster enquestarà el repositori per veure els canvis.
Hi ha diversos mètodes per fer un seguiment dels canvis al repositori d'un projecte.
El mètode més senzill és Votatge, que implica que BuildMaster sondeja periòdicament el servidor amb el repositori. Si cometre va reflectir els canvis al repositori, doncs BuildMaster crearà un objecte intern amb un cert retard Canviar i enviar-lo al gestor d'esdeveniments Programador, que posarà en marxa els passos per construir i provar el projecte Obrer-e. Entre aquests passos s'indicaran actualització repositori. Exactament encès ObrerAixò crearà una còpia local del dipòsit. Els detalls d'aquest procés es tractaran a continuació en les dues seccions següents. ( и ).
Un mètode encara més elegant per fer un seguiment dels canvis a un repositori és enviar missatges directament des del servidor que l'allotja BuildMaster- sobre el canvi dels codis font del projecte. En aquest cas, tan aviat com el desenvolupador fa cometre, el servidor amb el repositori del projecte enviarà un missatge BuildMaster-i. I ell, al seu torn, l'interceptarà creant un objecte PBChangeSource. A continuació, aquest objecte es transferirà a Programador, que activa els passos per construir el projecte i provar-lo. Una part important d'aquest mètode és treballar amb ganxo-scripts del servidor al repositori. En el guió ganxo-a, responsable del tractament de les accions quan cometre-e, cal trucar a la utilitat enviar canvi i especifiqueu l'adreça de xarxa BuildMaster-A. També heu d'especificar el port de xarxa que escoltarà PBChangeSource. PBChangeSource, per cert, forma part BuildMaster-A. Aquest mètode requerirà permís admin-a al servidor on es troba el repositori del projecte. Primer haureu de fer una còpia de seguretat del repositori.
5.4 programadors
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"]))
programadors – aquest és un element que actua com a detonant que inicia tota la cadena de muntatge i prova del projecte.
Aquells canvis que es van registrar canvi_font, transformada en el procés de treball BuildBot-a oposar-se Canviar i ara tots Sheduler a partir d'ells, crea sol·licituds per iniciar el procés de creació del projecte. Tanmateix, també determina quan aquestes sol·licituds es transfereixen a la cua. Un objecte Constructor emmagatzema una cua de sol·licituds i fa un seguiment de l'estat de l'assemblea actual per separat Obrer-És. Constructor existeix en BuildMaster-e i endavant Obrer-e. Ell envia amb BuildMaster-a on Obrer-i ja concret construir - una sèrie de passos que cal seguir.
Veiem que en l'exemple actual tal programadors Es creen 2 peces. A més, cadascun té el seu propi tipus.
SingleBranchScheduler – una de les classes més populars de l'horari. Observa una branca i s'activa per un canvi registrat. Quan veu canvis, pot retardar l'enviament de la sol·licitud de compilació (ajornar el període especificat al paràmetre especial treeStableTimer). IN nom estableix el nom de la programació que es mostrarà BuildBot- interfície web. EN Canvia el filtre s'estableix un filtre, després de passar quins canvis a la branca sol·liciten el calendari per enviar una sol·licitud de construcció. EN builderNames s'indica el nom constructor-a, que posarem una mica més endavant. El nom en el nostre cas serà el mateix que el nom del projecte: el teu projecte.
ForceScheduler una cosa molt senzilla. Aquest tipus de programació s'activa mitjançant un clic del ratolí BuildBot- interfície web. Els paràmetres tenen la mateixa essència que a SingleBranchScheduler.
PS núm. 3. Potser serà útil
Periòdic és un programa que s'executa amb una determinada freqüència fixada en el temps. La trucada sembla una cosa així
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 especifica el temps d'aquesta periodicitat en segons.
BuildFactory crea un específic construir, que aleshores constructor envia a Obrer. En BuildFactory indica els passos a seguir Obrer-i. Els passos s'afegeixen trucant al mètode addStep
El primer pas afegit en aquest exemple és git clean -d -f -f –x, llavors git checkout. Aquestes accions s'inclouen al paràmetre mètode, que no s'indica clarament però implica un valor predeterminat fresc... Paràmetre mode='incremental' indica que els fitxers són del directori on es troba el fitxer chechout, tot i que falten al repositori, romanen intactes.
El segon pas afegit és cridar l'script judici amb paràmetre Hola al costat Obrer-a del directori /home/habr/worker/yourProject/build amb la variable d'entorn PATHONPATH=... Així, podeu escriure els vostres propis scripts i executar-los al costat Obrer-a cada pas util.ShellCommand. Aquests scripts es poden col·locar directament al repositori. Després a les chechout-e cauran en /home/habr/worker/yourProject/build. Tanmateix, hi ha dos "peròs":
- Obrer s'ha de crear amb una clau de manera que no bloquegi els drets d'execució després caixa-El.
- En git push-e d'aquests scripts cal especificar la propietat exacutableperquè més tard chechout-e no va perdre el dret d'executar l'script Git.
5.6 constructors
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Sobre el que és Constructor es va dir . Ara us explicaré amb més detall com crear-lo. BuilderConfig és un constructor constructor. Aquests dissenyadors a c['constructors'] podeu especificar-ne diversos, ja que es tracta d'un full d'objectes constructor tipus. Ara tornem a escriure l'exemple de BuildBot, apropant-lo a la nostra tasca.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Ara us explicaré els paràmetres BuilderConfig.
nom especifica el nom constructor-a. Aquí li hem posat nom el teu projecte... Això vol dir que encès Obrer- aquest mateix camí es crearà /home/habr/worker/yourProject/build. Sheduler buscant constructor només amb aquest nom.
noms de treball conté un full Obrer-s. Cadascun dels quals cal afegir-hi c['treballadors'].
fàbrica - específic construir, amb la qual s'associa constructor. Ell enviarà l'objecte construir en Obrer per completar tots els passos inclosos en aquest construir-El.
6. Exemple de configuració pròpia
Aquí teniu l'exemple d'arquitectura del projecte que proposo implementar mitjançant BuildBot
.
Utilitzarem com a sistema de control de versions svn. El mateix repositori estarà situat en algun tipus de núvol. Aquí teniu l'adreça d'aquest núvol . Al núvol sota svn hi ha un nom d'usuari del compte: user, passwd: contrasenya. Guions que representen passos construir-a també estarà a la branca svn, en una carpeta a part buildbot/worker_linux. Aquests scripts es troben al repositori amb la propietat desada executable.
BuildMaster и Obrer executar al mateix host projecte.amfitrió .BuildMaster emmagatzema els seus fitxers en una carpeta /home/habr/master. Obrer s'emmagatzema al camí següent /home/habr/treballador. Comunicació del procés BuildMaster-a i Obrer-a es realitza a través del port 4000 segons el protocol BuildBot-a, és a dir 'pb' protocol.
El projecte objectiu està escrit completament en Python. La tasca és fer un seguiment dels seus canvis, crear un fitxer executable, generar documentació i realitzar proves. En cas d'error, tots els desenvolupadors han d'enviar un missatge per correu electrònic indicant que hi ha una acció sense èxit.
Visualització web BuildBot ens connectarem al port 80 per projecte.amfitrió. No cal instal·lar Apatch. Com a part de la biblioteca retorçat ja hi ha un servidor web, BuildBot l'utilitza.
Per emmagatzemar informació interna per BuildBot utilitzarem sqlite.
Es requereix un amfitrió per enviar el correu smtp.el teu.domini - permet enviar cartes des del correu [protegit per correu electrònic] sense autenticació. També a l'amfitriósmtp ' L'acta s'està escoltant al lloc 1025.
Hi ha dues persones implicades en el procés: admin и user. l'administrador administra BuildBot. l'usuari és la persona que es compromet cometre-s.
El fitxer executable es genera mitjançant pyinstaller. La documentació es genera mitjançant doxigen.
Per a aquesta arquitectura vaig escriure això: mestre.cfg:
mestre.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"
}
Primer cal BuildMaster-a i Obrer-a. A continuació, enganxeu aquest fitxer mestre.cfg в /home/habr/master.
El següent pas és iniciar el servei BuildMastera
sudo buildbot start /home/habr/master
A continuació, inicieu el servei Obrer-a
buildbot-worker start /home/habr/worker
A punt! Ara Buildbot farà un seguiment dels canvis i activarà cometre-i dins svn, realitzant els passos de construcció i prova d'un projecte amb l'arquitectura anterior.
A continuació descriuré algunes característiques de l'anterior mestre.cfg.
6.1 De camí cap al vostre mestre.cfg
Mentre escric el meu mestre.cfg Es cometreran molts errors, de manera que caldrà llegir el fitxer de registre. S'emmagatzema com a BuildMaster-ec camí absolut /home/habr/master/twistd.log, i al costat Obrer-a amb camí absolut /home/habr/worker/twistd.log. A mesura que llegiu l'error i el solucioneu, haureu de reiniciar el servei BuildMaster-a. Així és com es fa:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Treballar amb 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)
Per començar, donem-hi una ullada svn_poller. Aquesta segueix sent la mateixa interfície, consultant regularment el repositori una vegada per minut. En aquest cas svn_poller només accedeix a la sucursal tronc. Paràmetre misteriós split_file=util.svn.split_file_alwaystrunk estableix les regles: com trencar l'estructura de carpetes svn a les branques. També els ofereix camins relatius. Al seu torn split_file_alwaystrunk simplifica el procés dient que el repositori només conté tronc.
В Programadors indicat Canvia el filtrequi veu cap i hi associa una branca tronc segons una associació determinada a través split_file_alwaystrunk. Resposta als canvis en tronc, Llançaments constructor amb nom el teu projecte.
propietats aquí és necessari perquè l'administrador rebi llistes de correu de resultats de compilació i prova com a propietari del procés.
Pas construir-a caixa capaç d'esborrar completament qualsevol fitxer situat a la versió local del dipòsit Obrer-A. I després fer el ple svn actualització. El mode es configura mitjançant el paràmetre mode = ple, mètode = fresc... Paràmetre stopOnTailure diu que si svn actualització s'executarà amb un error, llavors s'hauria de suspendre tot el procés de construcció i prova, ja que les accions posteriors no tenen sentit.
6.3 Carta per a vostè: els periodistes estan autoritzats a declarar
periodistes és un servei d'enviament de notificacions per correu electrònic.
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]
Pot enviar missatges .
MailNotifier utilitza el correu electrònic per enviar notificacions.
template_html estableix la plantilla de text per al butlletí. HTML s'utilitza per crear marques. Està modificat pel motor (es pot comparar amb django). BuildBot té un conjunt de variables els valors de les quals es substitueixen a la plantilla durant el procés de generació del text del missatge. Aquestes variables estan tancades entre {{ claus dobles }}. Per exemple, resum mostra l'estat de les operacions finalitzades, és a dir, l'èxit o el fracàs. A projectes sortirà el teu projecte. Per tant, utilitzant les ordres de control jinja2, les variables BuildBot-a i eines de format de cadena de Python, podeu crear un missatge força informatiu.
MailNotifier conté els arguments següents.
fromaddr – l'adreça des de la qual tothom rebrà el butlletí.
sendToInterestedUsers=True envia un missatge al propietari i usuari que l'ha fet cometre.
lookup — un sufix que s'ha d'afegir als noms dels usuaris que reben el butlletí. Tan admin com rebrà l'usuari el butlletí a l'adreça [protegit per correu electrònic].
host de retransmissió especifica el nom d'amfitrió en què s'obre el servidor smtp, un smptPort especifica el número de port que escolta smtp servidor.
mode="advertència" diu que l'enviament només s'ha de fer si hi ha almenys un pas construir-a, que va acabar amb l'error o l'avís d'estat. En cas d'èxit, no cal enviar un butlletí.
ExtraDestinataris conté una llista de persones a les quals s'ha d'enviar l'enviament, a més del propietari i la persona que l'ha fet cometre.
messageFormatter és un objecte que especifica el format del missatge, la seva plantilla i un conjunt de variables disponibles jinja2. Opcions com ara wantProperties=Veritable и wantSteps=Veritat definir aquest conjunt de variables disponibles.
with['services']=[sendMessageToAll] ofereix una llista de serveis, entre els quals hi haurà el nostre reporter.
Ho hem fet! Felicitats
Hem creat la nostra pròpia configuració i hem vist la funcionalitat de la qual és capaç. BuildBot. Això, crec, és suficient per entendre si aquesta eina és necessària per crear el vostre projecte. Estàs interessat en ell? Us serà útil? És còmode treballar amb ell? Llavors no escric aquest article en va.
I més enllà. M'agradaria que la comunitat professional l'utilitzi BuildBot, es va fer més àmplia, es van traduir manuals i encara hi havia més exemples.
Gràcies a tots per la vostra atenció. Bona sort.
Font: www.habr.com