J'avais besoin de configurer le processus d'assemblage et de livraison des packages logiciels du référentiel Git au site. Et après avoir vu, il n'y a pas si longtemps, ici sur Habr l'article sur buildbot (le lien à la fin) a décidé de l'essayer et de le demander.
Puisque buildbot est un système distribué, il sera logique que chaque architecture et système d'exploitation crée un hôte d'assemblage distinct. Dans notre cas, ce seront des conteneurs LXC (dans le cas de linux) et qemu (dans le cas de windows):
- vm-srv-build1 - centos 7, il y aura un maître buildbot et l'un des ouvriers
- vm-srv-build2 - debian 10, pour la construction de paquets DEB
- vm-srv-build3 - windows 10, pour l'assemblage, vous comprenez vous-même
Nous allons collecter Rac GUI - une face graphique à 1C rac pour gérer un cluster de serveurs. Pour Linux, des outils standard pour chaque système d'exploitation seront utilisés, freewrap est utilisé pour créer un fichier exe pour Windows à partir d'un script tcl.
L'installation
GNU / Linux
Pour l'installation, la documentation sur le réseau suffit 1 , 2 . Et cela ne pose aucun problème particulier:
Pour le maître:
pip3 install buildbot pip3 install twisted pip3 install autobahn pip3 install pysqlite3 pip3 install sqlalchemy sqlalchemy-migrate pip3 install buildbot-www buildbot-grid-view buildbot-console-view buildbot-waterfall-view pip3 install python-dateutil
Pour les "travailleurs", cela suffit:
pip3 install buildbot-worker
Bien sûr, il serait plus correct de collecter des packages pour chaque système d'exploitation, mais cela n'est pas inclus dans la portée de l'article. Nous omettons également la description de la configuration des conteneurs pour le travail, je note seulement que j'utilise ProxMox VE. Et vous devez également installer des packages pour chaque axe requis pour l'assemblage (centos: rpmdevtools, etc.; debian: build-essential, dh-make, pbuilder, etc.)
Les services d'assemblage de projet et de buildbot seront lancés au nom d'un utilisateur non privilégié, vous devez donc le créer sur tous les hôtes impliqués dans le processus:
adduser buildbot
Ensuite, configurez le lancement automatique des services, respectivement, sur chacun des hôtes (conteneurs):
Unité Systemd pour exécuter l'assistant:
touch /etc/systemd/buildbot-master.service [Unit] Description=BuildBot master service After=network.target [Service] User=buildbot Group=buildbot WorkingDirectory=/home/buildbot/master ExecStart=/usr/local/bin/buildbot start --nodaemon ExecReload=/bin/kill -HUP $MAINPID [Install] WantedBy=multi-user.target
et "travailleur"
touch /etc/systemd/buildbot-worker.service [Unit] Description=BuildBot worker service After=network.target [Service]master User=buildbot Group=buildbot WorkingDirectory=/home/buildbot/worker ExecStart=/usr/local/bin/buildbot-worker start --nodaemon [Install] WantedBy=buildbot-master.service
Étant donné que tous les scripts (dans notre cas) se trouvent dans / usr / local /, vous devez écrire leur chemin d'accès dans les variables d'environnement:
nano /root/.bash_profile PATH=$PATH:$HOME/.local/bin:$HOME/bin:/usr/local/bin
Après cela, vous pouvez créer une infrastructure d'annuaire pour les "travailleurs" (sur tous les hôtes), pour cela, inscrivez-vous sous l'utilisateur buildbot et exécutez les commandes suivantes:
Sur le premier hôte, vm-srv-build1:
su - buildbot mkdir /home/buildbot/worker cd ~ buildbot-worker create-worker --umask=0o22 --keepalive=60 worker vm-srv-build1:4000 CentOS 123456
Sur le deuxième hôte, vm-srv-build2:
su - buildbot mkdir /home/buildbot/worker cd ~ buildbot-worker create-worker --umask=0o22 --keepalive=60 worker vm-srv-build1:4000 Debian-10 123456
Sur les hôtes actifs, le service buildbot-worker peut être démarré
systemctl start buildbot-worker
MS Windows
En tant que build "fonctionnel" pour Windows, une machine virtuelle avec la dernière version de Win10 sera utilisée.
Pour travailler, vous avez besoin de:
Une fois que tout ce qui précède est installé, vous pouvez installer buildbot lui-même:
pip install buildbot-worker
Créer un répertoire de travail
md c:\worker
Et courir
buildbot-worker start c:\worker
Si tout fonctionne (voir le journal c: \ worker \ twistd.log), vous pouvez enregistrer notre "worker" en tant que service en ajoutant un élément avec le répertoire de travail au registre (les commandes sont exécutées dans powershell en tant qu'administrateur):
buildbot_worker_windows_service.exe --user VM-SRV-BUILD3\buildbot --password 123456 --startup auto install New-ItemProperty -path Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BuildBot\Parameters -Name directories -PropertyType String -Value c:\worker
Et vous pouvez exécuter un serviteur
Start-Service buildbot
C’est tout avec les «travailleurs», alors vous n’avez plus à les toucher, toute la gestion vient du maître.
Assistant de configuration
Pour commencer, nous allons créer l'infrastructure de l'assistant (sur l'hôte principal), pour cela nous nous enregistrons sous l'utilisateur buildbot et exécutons les commandes suivantes:
su - buildbot mkdir /home/buildbot/master cd ~ buildbot create-master master
Pour les packages finis, créez le répertoire builds
mkdir /home/buildbot/builds
Le fichier master.cfg a été créé dans le répertoire / home / buildbot / master /. Ce fichier est un code python et contient une description de tous les mécanismes du système, nous continuerons à travailler avec lui.
nano /home/buildbot/master/master.cfg
import os, re from buildbot.plugins import steps, util, schedulers, worker, changes, reporters c= BuildmasterConfig ={}
Pour automatiser l'assemblage de packages de différentes versions, afin de ne pas avoir à grimper dans le code du fichier master.cfg, dans le script principal du programme rac_gui.tcl dans l'en-tête, des lignes avec la version et la version actuelles sont ajoutées:
Et sur la base de ces lignes, buildbot numérotera les packages. Pour extraire des données, utilisez l'appel grep de la console. Dans buildbot, vous ne pouvez tout simplement pas définir de variables pour les «travailleurs» (en tout cas, je n'ai pas trouvé comment). Pour ce faire, utilisez des propriétés. C'est-à-dire dans le processus d'assemblage, ajoutez les étapes pour déterminer la version et la version et, par conséquent, définissez les propriétés de version et de version. Les propriétés peuvent être définies de différentes manières, dans ce cas, il s'agit d'un appel à une commande de console:
Remplacez les valeurs obtenues en appelant util.Interpolate ().
Il convient de noter que, puisque l'hôte est également utilisé pour l'assemblage manuel des packages, l'assemblage se fera le long de chemins standard.
Pour définir les numéros de version et de version corrects, utilisez l'appel sed standard, c'est-à-dire la commande remplace les valeurs à l'intérieur du fichier de spécifications par les informations nécessaires
Nous copions le paquet assemblé fini et l'archivage avec les codes source sur le maître. Mais vous pouvez immédiatement copier des fichiers de votre bureau vers votre référentiel ou votre site Web.
Sur l'assistant, nous commençons le processus de copie des packages collectés vers l'hébergement FTP. Pour ce faire, utilisez le script tcl.
rac_gui_build_RPM.addStep( steps.MasterShellCommand( command=["/usr/local/bin/deploy-ftp.tcl", util.Interpolate("--local-file=/home/buildbot/builds/rac-gui-%(prop:version)s-%(prop:release)s.noarch.rpm"), util.Interpolate("--remote-file=uploads/rac-gui/rac-gui-%(prop:version)s-%(prop:release)s.noarch.rpm")] ) ) rac_gui_build_RPM.addStep( steps.MasterShellCommand( command=["/usr/local/bin/deploy-ftp.tcl", util.Interpolate("--local-file=/home/buildbot/builds/rac-gui-%(prop:version)s-%(prop:release)s.tar.gz"), util.Interpolate("--remote-file=uploads/rac-gui/rac-gui-%(prop:version)s-%(prop:release)s.tar.gz")] ) )
Sur elle avec RPM terminé. Commençons maintenant la description de l'algorithme d'assemblage pour le package DEB. Étant donné que les processus de création de packages pour différents systèmes sont indépendants les uns des autres, de nombreuses étapes seront répétées.
rac_gui_build_DEB = util.BuildFactory() rac_gui_build_DEB.addStep(steps.Git( repourl = 'https://bitbucket.org/svk28/rac-gui.git', haltOnFailure = True, submodules = True, mode='full', workdir='build', progress = True) )
Pour le paquet RPM, une partie des procédures suivantes est effectuée par rpm lui-même lors de l'assemblage et est décrite dans la spécification, pour debian vous devez le faire ici:
Et DEB est terminé, maintenant Windows!
rac_gui_build_WIN = util.BuildFactory() rac_gui_build_WIN.addStep(steps.Git( repourl = 'https://bitbucket.org/svk28/rac-gui.git', haltOnFailure = True, submodules = True, mode='full', workdir='build', progress = True) )
Puisque windows n'a pas grep et sed (ou y a-t-il?), Nous utiliserons powershell
Pour vous informer de l'état du processus d'assemblage, nous utiliserons l'e-mail
c['services'] = [] template=u'''\ <h4>Build status: {{ summary }}</h4> <p> Worker used: {{ workername }}</p> {% for step in build['steps'] %} <p> {{ step['name'] }}: {{ step['result'] }}</p> {% endfor %} <p><b> -- The Buildbot</b></p> ''' mailNotifier = reporters.MailNotifier(fromaddr="builder@domain.ru", sendToInterestedUsers=False, mode=('all'), extraRecipients=["admin@domain.ru"], relayhost="mail.domain.ru", smtpPort=587, smtpUser="builder@domain.ru", smtpPassword="******", messageFormatter=reporters.MessageFormatter( template=template, template_type='html', wantProperties=True, wantSteps=True)) c['services'].append(mailNotifier)
Nous enregistrons le fichier et vous pouvez essayer de démarrer le service de l'assistant:
systemctl restart buildbot-master
Dans le log, on vérifie que tout est en ordre avec la config et tout fonctionne comme d'habitude. Tous nos employés doivent maintenant se connecter, comme cela sera heureusement signalé dans le journal '' '' '' /home/buildbot/master/twistd.log '' '' ':
2019-07-24 16:50:35+0300 [-] Loading buildbot.tac... 2019-07-24 16:50:35+0300 [-] Loaded. 2019-07-24 16:50:35+0300 [-] twistd 19.2.1 (/usr/bin/python3.6 3.6.8) starting up. 2019-07-24 16:50:35+0300 [-] reactor class: twisted.internet.epollreactor.EPollReactor. 2019-07-24 16:50:35+0300 [-] Starting BuildMaster -- buildbot.version: 2.3.1 2019-07-24 16:50:35+0300 [-] Loading configuration from '/home/buildbot/master/master.cfg' 2019-07-24 16:50:36+0300 [-] /usr/local/lib/python3.6/site-packages/buildbot/config.py:90: buildbot.config.ConfigWarning: [0.9.0 and later] `buildbotNetUsageData` is not configured and defaults to basic. This parameter helps the buildbot development team to understand the installation base. No personal information is collected. Only installation software version info and plugin usage is sent. You can `opt-out` by setting this variable to None. Or `opt-in` for more information by setting it to "full". 2019-07-24 16:50:36+0300 [-] Setting up database with URL 'sqlite:/state.sqlite' 2019-07-24 16:50:36+0300 [-] setting database journal mode to 'wal' 2019-07-24 16:50:36+0300 [-] adding 1 new services, removing 0 2019-07-24 16:50:36+0300 [-] adding 1 new change_sources, removing 0 2019-07-24 16:50:36+0300 [-] gitpoller: using workdir '/home/buildbot/master/gitpoller-work' 2019-07-24 16:50:36+0300 [-] adding 3 new builders, removing 0 2019-07-24 16:50:36+0300 [-] adding 1 new schedulers, removing 0 2019-07-24 16:50:36+0300 [-] initializing www plugin 'waterfall_view' 2019-07-24 16:50:36+0300 [-] initializing www plugin 'console_view' 2019-07-24 16:50:36+0300 [-] initializing www plugin 'grid_view' 2019-07-24 16:50:36+0300 [-] NOTE: www plugin 'sitenav' is installed but not configured 2019-07-24 16:50:36+0300 [-] initializing www plugin 'waterfall_view' 2019-07-24 16:50:36+0300 [-] initializing www plugin 'console_view' 2019-07-24 16:50:36+0300 [-] initializing www plugin 'grid_view' 2019-07-24 16:50:36+0300 [-] NOTE: www plugin 'sitenav' is installed but not configured 2019-07-24 16:50:36+0300 [-] BuildbotSite starting on 80 2019-07-24 16:50:36+0300 [-] Starting factory <buildbot.www.service.BuildbotSite object at 0x7fe31c2657b8> 2019-07-24 16:50:36+0300 [-] adding 3 new workers, removing 0 2019-07-24 16:50:36+0300 [-] PBServerFactory starting on 4000 2019-07-24 16:50:36+0300 [-] Starting factory <twisted.spread.pb.PBServerFactory object at 0x7fe31c147470> 2019-07-24 16:50:37+0300 [-] BuildMaster is running 2019-07-24 16:50:37+0300 [-] buildbotNetUsageData: sending {'installid': 'b6193b126b96689351d2fe95787c5a03fc0879f9', 'versions': {'Python': '3.6.8', 'Buildbot': '2.3.1', 'Twisted': '19.2.1'}, 'platform': {'platform': 'Linux-4.15.18-10- pve-x86_64-with-centos-7.6.1810-Core', 'system': 'Linux', 'machine': 'x86_64', 'processor': 'x86_64', 'python_implementation': 'CPython', 'version': '#1 SMP PVE 4.15.18-32', 'distro': 'centos:7'}, 'plugins': {'buildbot/worker/base/Worker': 3, 'buildbot/config/BuilderConfig': 3, 'buildbot/schedulers/basic/SingleBranchScheduler': 1, 'buildbot/reporters/mail/MailNotifier': 1, 'buildbot/changes/gitpoller/GitPoller': 1, 'buildbot/steps/worker/MakeDirectory': 1, 'buildbot/steps/source/git/Git': 3, 'buildbot/steps/shell/ShellCommand': 9, 'buildbot/steps/package/rpm/rpmbuild/RpmBuild': 1}, 'db': 'sqlite', 'mq': 'simple', 'www_plugins': ['waterfall_view', 'console_view', 'grid_view']} 2019-07-24 16:50:37+0300 [Broker,0,127.0.0.1] worker 'CentOS' attaching from IPv4Address(type='TCP', host='127.0.0.1', port=37332) 2019-07-24 16:50:37+0300 [Broker,0,127.0.0.1] Got workerinfo from 'CentOS' 2019-07-24 16:50:37+0300 [-] bot attached 2019-07-24 16:50:37+0300 [Broker,0,127.0.0.1] Worker CentOS attached to Rac-GUI-RPM-builder 2019-07-24 16:50:37+0300 [-] buildbotNetUsageData: buildbot.net said: ok 2019-07-24 16:50:39+0300 [Broker,1,192.168.55.15] worker 'Windows-10' attaching from IPv4Address(type='TCP', host='192.168.5.145', port=49831) 2019-07-24 16:50:39+0300 [Broker,1,192.168.55.15] Got workerinfo from 'Windows-10' 2019-07-24 16:50:40+0300 [-] bot attached 2019-07-24 16:50:40+0300 [Broker,1,192.168.55.15] Worker Windows-10 attached to Rac-GUI-WIN-builder 2019-07-24 16:50:41+0300 [Broker,2,192.168.55.99] worker 'Debian-10' attaching from IPv4Address(type='TCP', host='192.168.5.9', port=44430) 2019-07-24 16:50:41+0300 [Broker,2,192.168.55.99] Got workerinfo from 'Debian-10' 2019-07-24 16:50:41+0300 [-] bot attached 2019-07-24 16:50:41+0300 [Broker,2,192.168.55.99] Worker Debian-10 attached to Rac-GUI-DEB-builder
Ceci termine le processus d'installation. Vous pouvez afficher l'état actuel via la face Web. Où vous pouvez également voir les erreurs d'assemblage, lancer un processus gelé en cas de problème, etc.
Immédiatement après le lancement de nos travailleurs acharnés, vous pouvez voir à travers le menu "Builds" -> "Workers"
Une fois le premier processus de génération terminé (c'est-à-dire les modifications apportées au référentiel Git), l'état des processus apparaîtra sur la première page.
Si vous piquez la souris dans la ligne souhaitée, une page s'ouvre avec l'état actuel du processus, où vous pouvez voir ce qui se passe, quelles erreurs, etc.
Vous pouvez prendre la configuration complète du master ici import os, re from buildbot.plugins import steps, util, schedulers, worker, changes, reporters c= BuildmasterConfig ={} c['workers'] = [ worker.Worker('CentOS', '123456'), worker.Worker('Debian-10', '123456'), worker.Worker('Windows-10', '123456')] c['protocols'] = {'pb': {'port': 4000}} c['change_source'] = [] c['change_source'].append(changes.GitPoller( repourl = 'https://bitbucket.org/svk28/rac-gui.git', project = 'Rac-GUI', branches = True, pollInterval = 600 ))
: