(Image by from
Bonjour !
Je m'appelle Evgueni Tcherkine, je suis programmeur dans l'équipe de développement d'une entreprise minière Polymetal.
En commençant tout grand projet, on commence à se demander : « Quel logiciel est le mieux à utiliser pour sa maintenance ? ». Un projet IT passe par plusieurs étapes avant la sortie d'une nouvelle version. C'est bien lorsque cette chaîne d'étapes est automatisée. Le processus automatisé de sortie d'une nouvelle version d'un projet IT s'appelle Intégration Continue. BuildBot s'est révélé être un bon assistant mettant en œuvre ce processus.
Dans cet article, j'ai décidé de présenter un aperçu des fonctionnalités BuildBot. Quelles sont les capacités de ce logiciel ? Comment s'y attaquer et comment établir des relations de travail normales et EFFICACES avec lui ? Vous pouvez appliquer notre expérience chez vous en créant sur votre machine un service de construction et de test pour votre projet.
Contenu
Contenu
1. Pourquoi BuildBot ?
Auparavant, sur habr-e, j'avais rencontré des articles sur la réalisation Intégration Continue à l'aide de BuildBot. Par exemple, m'a semblé le plus informatif. Il y a un autre exemple — . Ces articles peuvent être accompagnés , et en prime, en anglais. En somme, cela fait un bon point de départ. Après avoir lu ces articles, vous voudrez sûrement immédiatement faire quelque chose sur BuildBot .
Stop ! Est-ce que quelqu'un l'a déjà utilisé dans ses projets ? Il s'avère que oui, l'ont appliqué dans leurs tâches. On peut en trouver d'un système de tests automatisés de fuzzing développé par Google BuildBot même dans les archives de codes Google.
Alors quelle est la logique des personnes utilisant Buildbot? Ведь есть другие инструменты: CruiseControl et Jenkins. Je répondrai ainsi. Pour la plupart des tâches Jenkins cela suffira effectivement. En revanche, BuildBot — plus adaptable, et les tâches y sont résolues aussi simplement que dans Jenkins. C'est à vous de choisir. Mais puisque nous cherchons un outil pour un projet cible en développement, pourquoi ne pas choisir celui qui permettra, en partant de étapes simples, de créer un système de construction ayant interactivité et une interface unique.
Pour ceux dont le projet cible est écrit en Python, la question se pose : « Pourquoi ne pas choisir un système d'intégration qui dispose d'une interface claire par rapport au langage utilisé dans le projet ? ». C'est le moment idéal pour présenter les avantages BuildBot.
Alors, notre « quatuor d'outils ». Pour moi, j'ai défini quatre caractéristiques BuildBot:
- C'est un framework open source sous licence GPL
- C'est l'utilisation de Python comme outil de configuration et de description des actions nécessaires
- C'est la possibilité d'obtenir une réponse de la machine sur laquelle la construction a lieu
- Enfin, ce sont des exigences minimales pour l'hôte. Pour le déploiement, il faut Python et Twisted, sans nécessiter de machine virtuelle ni de machine Java.
2. La conception dirigée par BuildMaster
Le rôle central dans l'architecture de distribution des tâches est occupé par BuildMaster. Il se présente comme un service qui :
- suit les modifications dans l'arborescence des sources du projet
- envoie des commandes que le service Worker doit exécuter pour construire et tester le projet
- informe les utilisateurs des résultats des actions effectuées
BuildMaster est configuré via un fichier master.cfg. Ce fichier se trouve à la racine BuildMaster. Plus tard, je montrerai comment cette racine est créée. Le fichier lui-même master.cfg contient un script Python qui utilise des appels BuildBot.
L'objet le plus important suivant BuildBot s'appelle Worker. Ce service peut être exécuté sur un autre hôte avec un autre système d'exploitation, ou même sur celui où BuildMaster. Il peut également exister dans un environnement virtuel spécialement préparé avec ses propres paquets et variables. Ces environnements virtuels peuvent être créés à l'aide d'outils Python comme virtualenv, venv.
BuildMaster transmet les commandes à chaque Worker-è, et celui-ci les exécute. Donc, le processus de construction et de test du projet peut se faire sur Worker-e sous Windows et sur un autre Worker sous Linux.
Checkout du code source du projet se produit sur chaque Worker-e.
3. Installation
Alors, en avant. Comme hôte, j'utiliserai Ubuntu 18.04. Je vais y installer un BuildMaster-a et un Worker-a. Mais d'abord, il faudra installer Python 3.7 :
sudo apt-get update
sudo apt-get install python3.7
Pour ceux qui ont besoin de Python 3.7.2 au lieu de 3.7.1, vous pouvez faire ce qui suit :
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
L'étape suivante consiste à installer Twisted et BuildBot, ainsi que des packages permettant d'utiliser des fonctionnalités supplémentaires 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. Premiers pas
Il est temps de créer BuildMaster. Il se trouvera dans notre dossier /home/habr/master.
mkdir master
buildbot create-master master # C'est ici que nous le créonsL'étape suivante. Créons Worker. Il se trouvera dans notre dossier /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Lorsque vous lancerez Worker, par défaut, il créera dans /home/habr/worker un dossier avec le nom du projet indiqué dans master.cfg. Dans le dossier portant ce nom de projet, il créera un répertoire build, et y effectuera ensuite checkout. Le répertoire de travail pour Worker-a sera le répertoire /home/habr/yourProject/build.
La clé « Dorée »
Et maintenant, voici pourquoi j'ai écrit le paragraphe précédent : le script qui Maître demander à Worker-a de faire cela à distance dans ce répertoire ne sera pas exécuté, car le script n'a pas les droits d'exécution. Pour résoudre ce problème, une clé —umask=0o22, qui empêche l'écriture dans ce répertoire mais laisse les droits d'exécution, sera nécessaire. Et c'est tout ce dont nous avons besoin.
BuildMaster et Worker établir une connexion. Il arrive que celle-ci soit interrompue et Worker attend un moment une réponse de BuildMaster-a. Si aucune réponse n'est reçue, la connexion est relancée. La clé —keepalive=60 est précisément nécessaire pour indiquer le temps après lequel connect redémarrera.
5. Configuration. Recette étape par étape
Configuration BuildMaster est effectuée sur la machine où nous avons exécuté la commande create-master. Dans notre cas — il s'agit du répertoire /home/habr/master. Le fichier de configuration master.cfg n'existe pas encore, mais la commande a déjà créé le fichier master.cmg.sample. Il faut le renommer en master.cfg.sample dans master.cfg
mv master.cfg.sample master.cfgOuvrons ce master.cfg. Analysons sa composition. Après cela, nous tenterons de créer notre propre fichier de configuration.
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 — dictionnaire de configuration de base. Il doit être utilisé dans le fichier de configuration. Pour une utilisation simplifiée dans le code de configuration, un alias est introduit. «c». Noms dans c[«keyFromDist»] sont des éléments fixes pour interagir avec BuildMaster. Pour chaque clé, la valeur correspondante est insérée.
5.2 workers
c['workers'] = [worker.Worker("example-worker", "pass")]Cette fois, nous indiquons BuildMaster- une liste de Worker-s. Nous Worker avons créé , en précisant your-worker-name et password. Maintenant, ils doivent être indiqués à la place de example-worker et 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))
Avec la clé change_source du dictionnaire c, nous avons accès à la liste où nous devons placer l'objet qui interroge le dépôt avec le code source du projet. L'exemple utilise un dépôt Git, qui est interrogé à intervalles réguliers.
Le premier argument est le chemin de votre dépôt.
workdir représente le chemin vers le dossier où, côté Worker- sera stockée la version locale du dépôt. /home/habr/worker/yourProject/build La branche
contient la branche spécifique dans le dépôt à surveiller. pollInterval
contient le nombre de secondes après lesquelles le dépôt sera interrogé pour des modifications. BuildMaster Il existe plusieurs méthodes pour suivre les modifications dans le dépôt du projet.
La méthode la plus simple est
Le Polling Sondage, ce qui implique que BuildMaster le serveur interroge périodiquement le dépôt. En cas de commit modifications reflétées dans le dépôt, alors BuildMaster avec un certain délai, un objet interne Change sera créé et envoyé au gestionnaire d'événements Scheduler, qui lancera les étapes de construction et de test du projet sur Worker-e. Parmi ces étapes sera indiquée update du dépôt. C'est sur Worker-e que sera créée une copie locale du dépôt. Les détails de ce processus seront révélés ci-dessous dans les deux sections suivantes ( et ).
Une méthode encore plus élégante pour suivre les modifications dans le dépôt est l'envoi direct de messages depuis le serveur où il est hébergé, vers BuildMaster-e au sujet des modifications du code source du projet. Dans ce cas, dès que le développeur effectuera commit, le serveur du dépôt du projet enverra un message à BuildMaster-e. Celui-ci, à son tour, le capturera en créant un objet PBChangeSource. Cet objet sera ensuite transmis à Scheduler, qui activera les étapes de construction et de test du projet. Une partie importante de cette méthode est le travail avec les hook-scripts du serveur dans le dépôt. Dans le script hook-a, responsable du traitement des actions lors de commit-e, il est nécessaire d'appeler l'utilitaire sendchange et d'indiquer l'adresse réseau de BuildMaster-a. Il faut aussi indiquer le port réseau qui écoutera PBChangeSource. PBChangeSource, qui, soit dit en passant, fait partie de BuildMaster-a. Cette méthode nécessitera des droits admin-a sur le serveur où le dépôt du projet est situé. Il faudra d'abord faire une sauvegarde du dépôt.
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 – est un élément qui déclenche toute la chaîne de construction et de test du projet.
Les modifications qui ont été enregistrées change_source, se sont transformées au cours du processus BuildBot-a en un objet Change et maintenant chaque Sheduler base ses demandes de lancement du processus de construction du projet. Cependant, il définit aussi le moment où ces demandes doivent être envoyées dans la file d'attente. L'objet Builder conserve une file d'attente de demandes et suit l'état de la construction actuelle sur un Worker-e. Builder existe aussi sur BuildMaster-e et sur Worker-e. Il envoie de BuildMaster-a à Worker-a une série spécifique de build étapes à exécuter.
Nous voyons que dans l'exemple actuel, il y en a schedulers qui en créent 2. Chacune ayant son propre type.
SingleBranchScheduler – l'un des types de planification les plus populaires. Il observe une branche et se déclenche sur un changement enregistré en elle. Lorsqu'il détecte des modifications, il peut différer l'envoi d'une demande de construction (différer pour une période indiquée dans un paramètre spécial treeStableTimer). Dans nom le nom du calendrier à afficher dans BuildBot-l'interface web. Dans ChangeFilter un filtre est défini, en passant par lequel les changements dans la branche incitent le calendrier à envoyer une demande de construction. Dans builderNames le nom est spécifié builder-a, que nous définirons un peu plus tard. Dans notre cas, le nom sera le même que celui du projet : yourProject.
ForceScheduler est quelque chose de très simple. Ce type de planification se déclenche par un clic de souris via BuildBot-l'interface web. Les paramètres ont la même essence que dans SingleBranchScheduler.
P.S. n°3. Cela pourrait être utile
Périodique — il s'agit d'un calendrier qui se déclenche avec une périodicité fixe au niveau du temps. L'appel ressemble environ à ceci
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 définit le temps de cette périodicité en secondes.
BuildFactory crée un build, qui est ensuite builder envoyé à Worker. Il y a BuildFactory définir les étapes à exécuter Worker-u. Les étapes sont ajoutées par un appel de méthode addStep
La première étape ajoutée dans cet exemple est git clean -d -f -f –x, puis git checkout. Ces actions sont prévues dans le paramètre méthode, qui n'est pas explicitement indiqué mais implique une valeur par défaut fresh. Le paramètre mode=’incremental’ indique que les fichiers du répertoire où se fait le checkout, tout en étant absents du dépôt, restent intacts.
La deuxième étape ajoutée est l'appel d'un script trial c avec le paramètre hello côté Worker-a depuis le répertoire /home/habr/worker/yourProject/build c la variable d'environnement PATHONPATH=… Ainsi, vous pouvez écrire vos scripts et les exécuter côté Worker-a via l'étape util.ShellCommand. Ces scripts peuvent être placés directement dans le dépôt. Alors lors de checkout-e ils seront inclus dans /home/habr/worker/yourProject/build. Toutefois, il y a deux « mais » :
- Worker doit être créé avec la clé pour qu'il ne bloque pas les droits d'exécution après checkout-a.
- En cas git push-e ces scripts doivent indiquer la propriété exacutable, afin qu'ensuite lors de checkout-e les droits d'exécution du script Git ne soient pas perdus.
5.6 builders
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
De ce qu'est Builder il a été dit . Je vais maintenant vous expliquer en détail comment le créer. BuilderConfig est un constructeur builder. On peut définir plusieurs de ces constructeurs dans c[‘builders’] car il s'agit d'une liste d'objets builder type. À présent, nous allons un peu réécrire l'exemple pour BuildBot, l'adaptant à notre tâche.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Je vais maintenant vous parler des paramètres BuilderConfig.
nom qui définit le nom builder-a. Ici nous l'avons nommé yourProject. Cela signifie que dans Worker-e ce chemin sera créé /home/habr/worker/yourProject/build. Sheduler qui est trouvé builder justement par ce nom.
workernames contient une liste Worker-s. Chacun d'eux doit être ajouté dans c[‘workers’].
factory est un particulier build, avec lequel il est associé builder. Il enverra un objet build sur Worker pour exécuter toutes les étapes comprises dans ce build-a.
6. Exemple de configuration personnalisée
Voici l'architecture de l'exemple de projet que je propose de réaliser via BuildBot
.
Nous allons utiliser comme système de contrôle de version svn. Le dépôt sera situé dans un certain cloud. Voici l'adresse de ce cloud . Dans le cloud, il y a un compte username: svn , passwd: user. Les scripts, qui représentent des étapes password-a seront également dans la branche build, dans un dossier séparé svnbuildbot/worker_linux . Ces scripts sont dans le dépôt avec la propriété sauvegardéeexecutable fonctionnent sur un même hôte.
BuildMaster et Worker project.host stocke ses fichiers dans le dossier .BuildMaster les conserve au chemin suivant /home/habr/master. Worker . La communication entre les processus /home/habr/worker-a et BuildMaster-a se fait par le port 4000 via le protocole Worker-a, c'est-à-dire BuildBot‘pb’ protocole. Le projet cible est entièrement écrit en python. L'objectif est de suivre ses modifications, de créer un fichier exécutable, de générer de la documentation, de procéder à des tests. En cas d'échec, il faut envoyer un message par e-mail à tous les développeurs pour les informer qu'il y a une action échouée.
L'affichage web
sera connecté au port 80 pour BuildBot . Il n'est pas nécessaire d'installer Apache. Dans la bibliothèque stocke ses fichiers dans le dossiertwisted le serveur web est déjà inclus, il l'utilise. BuildBot Pour le stockage d'informations à usage interne, nous allons utiliser
Pour le stockage des informations à usage interne pour BuildBot Pour l'envoi d'e-mails, un hôte est nécessaire sqlite.
smtp.your.domain — il est autorisé d'envoyer des e-mails depuis l'adresse projectHost@your.domain sans authentification. De même, sur l'hôte ‘ smtp‘ le protocole écoute sur le port 1025. Les personnes impliquées dans le processus sont deux :
. admin administre admin et user. user est la personne qui effectue les BuildBot-s. commit-s.
Le fichier Exacutable est généré via pyinstaller. La documentation est générée avec doxygen.
Pour cette architecture, j'ai écrit ce qui suit 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>Statut de la version construite : {{ summary }}</h4>
<p>Service utilisé pour la construction : {{ workername }}</p>
<p>Projet : {{ projects }}</p>
<p>Pour voir l'interface de gestion, veuillez suivre le lien : {{ buildbot_url }}</p>
<p>Pour voir le résultat de la construction, veuillez suivre le lien : {{ build_url }}</p>
<p>Utilisez WinSCP pour vous connecter au serveur avec l'IP : xxx.xx.xxx.xx. En vous connectant avec habr/password, récupérez le fichier exécutable construit dans le répertoire ~/worker/yourProject/build/dist.</p>
<p><b>La construction a été effectuée 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'] = "Le processus de construction"
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"
}
Tout d'abord, il est nécessaire de BuildMaster-a se fait par le port 4000 via le protocole Worker-a. Ensuite, insérer ce fichier master.cfg dans /home/habr/master.
La prochaine étape consiste à lancer le service BuildMaster-a
sudo buildbot start /home/habr/master
Ensuite, démarrer le service Worker-a
buildbot-worker start /home/habr/worker
C'est prêt ! Maintenant Buildbot va suivre les changements et s'activer selon commit-u dans svn, exécutant les étapes de construction et de test du projet avec l'architecture mentionnée ci-dessus.
Ci-dessous, je vais détailler certaines caractéristiques du master.cfg.
6.1 En route vers mon master.cfg
Lors de l'écriture de votre master.cfg de nombreuses erreurs seront commises, il sera donc nécessaire de lire le fichier log. Il est stocké à la fois dans BuildMaster-e c avec un chemin absolu /home/habr/master/twistd.log, et du côté Worker-a avec un chemin absolu /home/habr/worker/twistd.log. En lisant, en corrigeant les erreurs, il sera nécessaire de redémarrer le service BuildMaster-a. Voici comment procéder :
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Travail avec 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)
Pour commencer, jetons un coup d'œil à svn_poller. C'est la même interface qui interroge régulièrement le dépôt toutes les minutes. Dans ce cas, svn_poller elle ne consulte que la branche trunk. Le paramètre mystérieux split_file=util.svn.split_file_alwaystrunk définit les règles : comment diviser la structure des dossiers svn en branches. Cela offre également des chemins relatifs. À son tour, split_file_alwaystrunk simplifie le processus, indiquant que dans le dépôt, il n'y a que des trunk.
Dans Schedulers qui sont spécifiés ChangeFilter, qui voit TSSAA et l'associe à une branche trunk par l'association définie à travers split_file_alwaystrunk. Réagissant aux changements dans trunk, il déclenche builder c nommé yourProject.
properties qui est nécessaire pour que l'admin reçoive des notifications sur les résultats de construction et de test en tant que propriétaire du processus.
Étape build-a checkout peut faire la suppression complète de tous les fichiers présents dans la version locale du dépôt Worker-a. Puis effectuer une mise à jour complète svn update.Le mode est configuré via le paramètre mode=full, method=fresh. Le paramètre haltOnTailure indique que si svn update. une erreur se produit, l'ensemble du processus de construction et de test doit être suspendu, car toute action ultérieure serait inutile.
6.3 Vous avez un message : reporters autorisé à déclarer
reporters est un service d'envoi de notifications par email.
template_html=u'''
<h4>Statut de la version construite : {{ summary }}</h4>
<p>Service utilisé pour la construction : {{ workername }}</p>
<p>Projet : {{ projects }}</p>
<p>Pour voir l'interface de gestion, veuillez suivre le lien : {{ buildbot_url }}</p>
<p>Pour voir le résultat de la construction, veuillez suivre le lien : {{ build_url }}</p>
<p>Utilisez WinSCP pour vous connecter au serveur avec l'IP : xxx.xx.xxx.xx. En vous connectant avec habr/password, récupérez le fichier exécutable construit dans le répertoire ~/worker/yourProject/build/dist.</p>
<p><b>La construction a été effectuée 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]
Il peut envoyer des messages .
MailNotifier utilise le courrier pour envoyer des notifications.
template_html définit le modèle de texte pour l'envoi. Pour créer la mise en page, on utilise html. Il est modifié par le moteur (comparable à django). BuildBot a un ensemble de variables, dont les valeurs sont insérées dans le modèle au moment de la création du texte du message. Ces variables sont encadrées par {{ doubles accolades }}. Par exemple, résumé affiche le statut des opérations effectuées, c'est-à-dire success ou failure. Et projects affichera yourProject. Ainsi, à l'aide des commandes de contrôle dans jinja2, des variables BuildBot-a et des outils de formatage de chaînes python, il est possible de créer un message assez informatif.
MailNotifier contient les arguments suivants.
fromaddr – l'adresse d'où proviendront les courriels envoyés.
sendToInterestedUsers=True envoie le message au propriétaire et à l'utilisateur ayant effectué le commit.
lookup – le suffixe à ajouter aux noms des utilisateurs recevant le message. Par conséquent, admin l'utilisateur recevra le message à l'adresse admin@your.domain.
relayhost définit le nom de l'hôte sur lequel le serveur est ouvert ‘ le protocole écoute sur le port 1025., a smptPort définit le numéro de port qui écoute ‘ le protocole écoute sur le port 1025. un serveur.
mode=«warning» indique que l'envoi doit être effectué uniquement si au moins une étape build-a s'est terminée avec le statut failure ou warning. En cas de success, l'envoi n'est pas nécessaire.
extraRecipients contient une liste de personnes à qui envoyer le message, en plus du propriétaire et de la personne ayant effectué le commit.
messageFormatter est un objet qui définit le format du message, son modèle et l'ensemble des variables disponibles de jinja2. Des paramètres tels que wantProperties=True et wantSteps=True définissent cet ensemble de variables disponibles.
s[‘services’]=[sendMessageToAll] fournit une liste de services, parmi lesquels se trouvera notre reporter.
Nous l'avons fait ! Mes félicitations
Nous avons créé notre propre configuration et avons vu les fonctionnalités capables de BuildBot. Cela, me semble suffisant pour comprendre si cet outil est nécessaire pour créer votre projet. Est-il intéressant pour vous ? Vous sera-t-il utile ? Est-il pratique à utiliser ? Alors je n'ai pas écrit cet article en vain.
Et encore. J'aimerais que la communauté professionnelle utilisant BuildBot, devienne plus large, que les manuels soient traduits et que les exemples soient de plus en plus nombreux.
Merci à tous pour votre attention. Bonne chance.
Source : habr.com
