TOC

Comment configurer l’intégration continue avec Buildbot sur Ubuntu 16.04

introduction

Buildbot est un système d’intégration continue basé sur Python permettant d’automatiser les processus de création, de test et de publication de logiciels. Dans les didacticiels précédents, nous Builded Buildbot, https://www.digitalocean.com/ communauté / didacticiels / comment-créer-système-fichiers-unités-pour-buildbot [fichiers système créés] afin de permettre au système init du serveur de gérer les processus et https://www.digitalocean.com/community/tutorials / how-to-configure-buildbot-with-ssl-using-an-nginx-reverse-proxy [configuré Nginx en tant que proxy inverse] afin de diriger les demandes de navigateur sécurisées par SSL vers l’interface Web de Buildbot.

Dans ce guide, nous montrerons comment configurer un système d’intégration continue pour tester automatiquement les nouvelles modifications apportées à un référentiel. Nous allons utiliser une simple application Node.js pour démontrer le processus de test et la configuration nécessaire. Pour isoler notre environnement de test de l’hôte Buildbot, nous allons créer une image Docker à exécuter en tant que notre agent Buildbot. Nous allons ensuite configurer le maître Buildbot pour qu’il surveille les modifications dans le référentiel GitHub, en testant automatiquement chaque nouvelle modification détectée.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de:

En outre, vous devrez suivre les didacticiels suivants sur le serveur:

Lorsque vous avez rempli ces conditions, vous êtes prêt à commencer.

Placer le référentiel d’exemples dans GitHub

Avant de commencer à configurer Buildbot, nous allons jeter un coup d’œil au référentiel d’exemple que nous allons utiliser pour ce guide.

Dans votre navigateur Web, visitez l’application hello hapi sur GitHub que nous utiliserons à des fins de démonstration. Cette application est un simple programme «hello world» avec quelques tests unitaires et d’intégration, écrite en hapi, un framework Web Node.js.

Comme cet exemple est utilisé pour illustrer divers systèmes d’intégration continue, vous remarquerez peut-être que certains fichiers sont utilisés pour définir des pipelines pour d’autres systèmes. Pour Buildbot, nous allons définir les étapes de construction sur le serveur plutôt que dans le référentiel.

Plus tard, nous allons configurer des webhooks pour Buildbot dans notre référentiel afin que les modifications déclenchent automatiquement de nouveaux tests. Pour l’instant, nous devons créer notre propre fork du référentiel.

Cliquez sur le bouton * Fourchette * dans le coin supérieur droit de l’écran:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/fork_repository.png [Bouton de référentiel de fourchette GitHub]

Si vous êtes membre d’une organisation GitHub, on vous demandera peut-être où vous souhaitez ouvrir le référentiel:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/where_to_fork.png [GitHub où insérer le référentiel]

Une fois que vous avez sélectionné un compte ou une organisation, une copie du référentiel sera ajoutée à votre compte:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/your_fork.png [GitHub votre fork]

Vous utiliserez l’URL de votre fork dans la configuration de Buildbot. Maintenant que nous avons une URL de référentiel, nous pouvons commencer à configurer Buildbot.

Configurer Docker pour Buildbot

Nous allons commencer par configurer Docker pour que Buildbot l’utilise pour effectuer des constructions. Tout d’abord, nous devons configurer l’accès entre Docker et Buildbot. Ensuite, nous devons créer une image Docker à utiliser pour nos conteneurs.

Configurer l’accès à Docker pour Buildbot

Nous devons permettre à Buildbot et Docker de communiquer à plusieurs niveaux.

Premièrement, nous devons nous assurer que le processus Buildbot a accès au démon Docker. Nous pouvons le faire en ajoutant l’utilisateur * buildbot * au groupe * docker *:

sudo usermod -aG docker buildbot

Ce nouveau groupe sera disponible pour Buildbot au prochain redémarrage du maître Buildbot, ce que nous ferons plus tard.

Nous devons également nous assurer que Buildbot sait comment communiquer avec Docker. Depuis que Buildbot est écrit en Python, il exploite le paquet https://docker-py.readthedocs.io/fr/stable/ [+ docker-py + Python] au lieu d’émettre directement des commandes Docker.

Vous pouvez installer + docker-py + en tapant:

sudo -H pip install docker-py

Enfin, nous devons ouvrir l’accès réseau des conteneurs au système hôte et au monde extérieur. Nous pouvons le faire en autorisant une exception pour l’interface + docker0 + dans notre pare-feu.

Autorisez l’accès au trafic à partir de l’interface + docker0 + en tapant:

sudo ufw allow in on docker0

Buildbot et Docker devraient maintenant être en mesure de communiquer efficacement les uns avec les autres.

Créer une image Docker à utiliser comme ouvrier de buildbot

Ensuite, nous allons créer un conteneur Docker à utiliser en tant qu’agent Buildbot pour exécuter nos tests. Buildbot peut démarrer dynamiquement les conteneurs Docker pour les utiliser en tant que travailleurs, mais les conteneurs doivent d’abord être générés avec certains composants de travail Buildbot inclus.

Heureusement, le projet Buildbot fournit une image de base https://hub.docker.com/r/buildbot/worker/worker/Buildbot] qui a déjà toutes les exigences spécifiques à Buildbot configurées. Nous devons simplement utiliser cette image comme base et installer les dépendances supplémentaires requises par notre projet.

Dans notre cas, l’application exemple que nous allons utiliser est une application Node.js. Nous devons donc nous assurer que Node.js est disponible sur l’image.

Pour définir notre image, créez et ouvrez un fichier nommé + Dockerfile + dans votre répertoire personnel:

nano ~/Dockerfile

Dans ce fichier, nous basons notre image sur l’image de l’ouvrier Buildbot en utilisant + FROM buildbot / buildbot-worker: master +. Ensuite, nous pouvons passer à l’utilisateur + root + pour installer Node.js, puis revenir à l’utilisateur + buildbot + pour exécuter les commandes réelles:

~ / Dockerfile

FROM buildbot/buildbot-worker:master

USER root
RUN curl -sL https://deb.nodesource.com/setup_8.x | bash -
RUN apt-get install -y nodejs
USER buildbot

Enregistrez et fermez le fichier lorsque vous avez terminé.

Une fois que nous avons un + Dockerfile, nous pouvons en construire notre image. Nous allons appeler l’image + npm-worker + pour être explicite sur les dépendances supplémentaires que nous avons installées:

docker build -t npm-worker - < ~/Dockerfile

Docker va commencer à construire votre image en fonction des commandes que nous avons décrites dans le + Dockerfile +. Il va extraire l’image de base et ses couches de dépendance, installer Node.js, puis enregistrer l’environnement résultant sous une image appelée + npm-worker +.

Configurez le Buildbot Master

Maintenant que nous avons une image Docker, nous pouvons configurer le maître Buildbot pour l’utiliser.

Parce que nous définissons un processus de construction entièrement nouveau et que nos personnalisations pour la configuration principale ont été minimales, nous allons commencer notre configuration à partir de zéro. Pour éviter de perdre les informations actuelles, nous allons déplacer le fichier d’origine dans un fichier de sauvegarde:

sudo mv /home/buildbot/master/master.cfg /home/buildbot/master/master.cfg.bak

Affichez la configuration du fichier de sauvegarde afin de pouvoir copier quelques valeurs importantes à utiliser dans notre nouvelle configuration:

sudo cat /home/buildbot/master/master.cfg.bak

Les informations importantes que nous souhaitons transférer dans la nouvelle configuration sont les informations d’identification et les autorisations de l’utilisateur. Recherchez les sections de configuration commençant par + c ['www'] ['authz'] + et + c ['www'] ['auth'] + dans le résultat:

Output. . .
c['www']['authz'] = util.Authz(
       allowRules = [
               util.AnyEndpointMatcher(role="admins")
       ],
       roleMatchers = [
               util.RolesFromUsername(roles=['admins'], usernames=[''])
       ]
)
c['www']['auth'] = util.UserPasswordAuth({'': ''})
. . .

Copiez et enregistrez ces lignes quelque part afin que vous puissiez les référencer plus tard. Nous ajouterons ces informations à notre nouvelle configuration principale Buildbot afin de préserver nos paramètres d’utilisateur et d’authentification.

Maintenant, créez un nouveau fichier + master.cfg + où nous pouvons redéfinir le comportement de notre instance Buildbot:

sudo nano /home/buildbot/master/master.cfg

Nous définirons notre nouvelle configuration principale Buildbot dans ce fichier.

Configurer une configuration de projet de base

Le fichier de configuration Buildbot est en fait un module Python, ce qui offre une grande flexibilité aux dépens d’une certaine complexité.

Nous allons commencer par une configuration de base. Collez les lignes suivantes dans votre fichier:

/home/buildbot/master/master.cfg

# -*- python -*-
# ex: set filetype=python:
from buildbot.plugins import *


c = BuildmasterConfig = {}

# Basic config
c['buildbotNetUsageData'] = None
c['title'] = "Hello Hapi"
c['titleURL'] = "https://github.com//hello_hapi"
c['buildbotURL'] = "https:///"
c['protocols'] = {'pb': {'port': 9989}}

La partie supérieure du fichier contient quelques commentaires que de nombreux éditeurs de texte sont capables d’interpréter pour appliquer correctement la coloration syntaxique. Ensuite, nous importons tout du paquet + buildbot.plugins + afin de disposer des outils nécessaires pour construire notre configuration.

La configuration de Buildbot est définie par un dictionnaire nommé + BuildmasterConfig +, nous avons donc défini cette variable sur un dictionnaire vide pour démarrer. Nous créons une variable abrégée nommée + c + définie sur ce même dictionnaire afin de réduire la quantité de frappe nécessaire dans tout le fichier.

Quelques points à noter dans la configuration qui suit:

  • + buildbot GetImageData est défini sur` + None`. Changez ceci en la chaîne " basic " si vous voulez rapporter les données d’utilisation aux développeurs.

  • Les éléments + title + et + titleURL + reflètent le nom du projet et le référentiel GitHub. Utilisez le lien vers votre propre fourche.

  • + buildbotURL + est défini sur le nom de domaine sécurisé par le maître Buildbot du SSL. N’oubliez pas de commencer par + https: // + et de terminer par une barre oblique / / .

  • Contrairement à notre dernière configuration, la définition + protocol ne se lie pas à localhost. Nous devons autoriser les connexions depuis les conteneurs Docker via le réseau de pont Docker + docker0 +.

Configurer le travailleur Docker

Ensuite, nous devons définir notre travailleur Docker. Buildbot utilisera Docker pour provisionner les travailleurs au besoin. Pour ce faire, il doit savoir comment se connecter à Docker et quelle image utiliser.

Collez ce qui suit au bas du fichier:

/home/buildbot/master/master.cfg

. . .

# Workers
c['workers'] = []
c['workers'].append(worker.DockerLatentWorker("npm-docker-worker", None,
                       docker_host='unix://var/run/docker.sock',
                       image='npm-worker',
                       masterFQDN=''))

La ligne + c ['workers'] = [] + illustre une convention de base que nous utiliserons au cours de la configuration. Nous définissons une clé dans le dictionnaire de configuration sur une liste vide. Nous ajoutons ensuite des éléments à la liste pour implémenter la configuration réelle. Cela nous donne la possibilité d’ajouter des éléments supplémentaires ultérieurement.

Pour définir notre travailleur, nous créons et ajoutons une instance + worker.DockerLatentWorker + à la liste + worker +. Nous appelons ce travailleur + npm-docker-worker + afin de pouvoir y faire référence ultérieurement dans la configuration. Nous définissons ensuite le + docker_host + sur l’emplacement du socket de Docker et fournissons le nom de l’image Docker que nous avons créée (+ npm-worker + dans notre cas). Nous définissons + masterFQDN + sur le nom de domaine de notre maître Buildbot pour nous assurer que le conteneur peut atteindre le maître, quels que soient les paramètres de nom d’hôte interne du serveur.

Configurer un ordonnanceur

Ensuite, nous allons définir un planificateur. Buildbot utilise des planificateurs pour décider quand et comment exécuter des générations en fonction des modifications reçues de sources de changement ou de crochets de changement (nous configurerons un crochet de changement ultérieurement).

Collez la configuration suivante au bas du fichier:

/home/buildbot/master/master.cfg

. . .

# Schedulers
c['schedulers'] = []
c['schedulers'].append(schedulers.SingleBranchScheduler(
               name="hello_hapi",
               change_filter=util.ChangeFilter(project='/hello_hapi', branch='master'),
               treeStableTimer=3,
               builderNames=["npm"]))

Nous utilisons la même méthode pour ajouter notre configuration à une liste vide ici. Dans ce cas, nous ajoutons une instance + schedulers.SingleBranchScheduler +. Cela nous permet de surveiller une seule branche sur le référentiel, ce qui simplifie la configuration.

Nous appelons le planificateur «hello_hapi» pour l’identifier correctement. Nous définissons ensuite un filtre de changement. De nombreux ensembles de modifications provenant de sources différentes peuvent être transmis à un planificateur. Les filtres de changement définissent un ensemble de critères qui détermineront si le changement en question doit être traité par ce planificateur particulier. Dans notre cas, nous filtrons en fonction du nom du projet, qui sera signalé par le Webhook de GitHub, et de la branche que nous souhaitons surveiller.

Nous définissons ensuite le paramètre + treeStableTimer +, qui détermine le délai d’attente des modifications supplémentaires, à 3 secondes. Cela aide à empêcher Buildbot de mettre en file d’attente de nombreuses petites constructions pour des modifications étroitement liées. Enfin, nous définissons les noms des générateurs à utiliser lorsqu’un changement correspond à nos critères (nous définirons ce générateur dans un moment).

Configurer une fabrique de construction pour les projets Node.js

Ensuite, nous allons configurer une fabrique de compilation pour gérer les projets Node.js. Une usine de construction est responsable de la définition des étapes à suivre pour construire, ou dans notre cas, un projet. Pour ce faire, il définit une instance + util.BuildFactory + puis ajoute des étapes séquentielles à exécuter.

Collez ce qui suit au bas de votre fichier:

/home/buildbot/master/master.cfg

. . .

# Build Factories
npm_f = util.BuildFactory()
npm_f.addStep(steps.GitHub(repourl='git://github.com//hello_hapi.git', mode='full', method='clobber'))
npm_f.addStep(steps.ShellCommand(command=["npm", "install"]))
npm_f.addStep(steps.ShellCommand(command=["npm", "test"]))

Premièrement, nous définissons une fabrique de construction appelée + npm_f +. La première étape que nous ajoutons est une instance + steps.GitHub. Ici, nous définissons le référentiel qui doit être descendu dans le constructeur. Nous définissons + mode sur« full »et la méthode` + i` sur «clobber» pour nettoyer complètement notre référentiel chaque fois que nous extrayons du nouveau code.

Les deuxième et troisième étapes que nous ajoutons sont les objets steps.ShellCommand +, qui définissent les commandes shell à exécuter dans le référentiel lors de la construction. Dans notre cas, nous devons exécuter + npm install + pour rassembler les dépendances du projet. Ensuite, nous devons exécuter + npm test pour exécuter votre suite de tests. Définir les commandes sous forme de liste (+ [" npm "," install "] +) est recommandé dans la plupart des cas pour empêcher le shell d’appliquer des extensions non souhaitées aux éléments de la commande.

Configurer un constructeur

Une fois que nous avons une fabrique de construction avec les étapes ajoutées, nous pouvons configurer un générateur. Le générateur associe un grand nombre des éléments déjà définis pour déterminer le mode d’exécution d’une génération.

Collez la configuration suivante au bas du fichier:

/home/buildbot/master/master.cfg

. . .

# Builders
c['builders'] = []
c['builders'].append(
       util.BuilderConfig(name="npm",
               workernames=["npm-docker-worker"],
               factory=npm_f))

Nous ajoutons un objet + util.BuilderConfig + à la liste + constructeurs +. Rappelez-vous que notre fabrique de construction s’appelle + npm_f +, que notre ouvrier Docker s’appelle + npm-docker-worker +, et que le planificateur que nous avons défini passera des tâches à un ouvrier nommé + npm +. Notre générateur définit la relation entre ces éléments afin que les modifications apportées par notre planificateur entraînent l’exécution des étapes de la fabrique de génération dans le serveur Docker.

Configurer la base de données et l’interface Web

Enfin, nous pouvons configurer les paramètres de la base de données et de l’interface Web. Contrairement à la plupart des éléments précédents, ces deux paramètres sont définis comme des dictionnaires plutôt que des listes. Le dictionnaire + db + pointe simplement sur le fichier + state.sqlite + déjà présent dans notre répertoire + / home / buildbot / master +. Le dictionnaire + www + contient une quantité importante de configuration supplémentaire.

Collez ce qui suit au bas de votre fichier. Remplacez les informations d’authentification que vous avez copiées à partir de votre configuration maître Buildbot d’origine pour le bloc d’authentification ci-dessous:

/home/buildbot/master/master.cfg

. . .

# Database
c['db'] = { 'db_url': "sqlite:///state.sqlite",}

# Web Interface
c['www'] = dict(port=8010, plugins=dict(waterfall_view={}, console_view={}))













# GitHub webhook receiver
c['www']['change_hook_dialects'] = {
       'github': {
               'secret': '',
               'strict': True,
       }
}

Après avoir défini les paramètres de la base de données, nous créons un dictionnaire + www + qui commence par définir le port d’écoute et certaines des vues à inclure dans l’interface utilisateur Web. Ensuite, nous ajoutons les exigences d’authentification extraites du fichier de configuration précédent de Buildbot.

À la fin, nous définissons un dictionnaire appelé + change_hook_dialects + dans le dictionnaire + www +. Nous l’utilisons pour définir un crochet de changement GitHub, qui écoutera les messages Webhook de GitHub. Choisissez une phrase secrète sécurisée pour votre + secret +, qui sera utilisée par GitHub pour authentifier les messages qu’il enverra.

Lorsque vous avez terminé, enregistrez et fermez le fichier.

Redémarrez Buildbot Master pour appliquer la nouvelle configuration

À ce stade, nous avons complètement reconfiguré le processus maître Buildbot. Nous devons redémarrer le processus maître Buildbot pour implémenter les modifications.

Avant de le faire, il est important de vérifier les erreurs de syntaxe dans votre fichier. Depuis que nous avons reconstruit la configuration à partir de zéro, il y a de fortes chances que nous ayons commis quelques erreurs.

Vérifiez la syntaxe du fichier en tapant:

sudo buildbot checkconfig /home/buildbot/master

La commande signalera tout problème détecté. Si aucune erreur n’a été trouvée, vous recevrez un message qui ressemble à ceci:

OutputConfig file is good!

Si des erreurs sont signalées, essayez de mieux comprendre ce qui ne va pas en lisant attentivement le message d’erreur. Ouvrez à nouveau le fichier de configuration pour essayer de résoudre les problèmes.

Lorsqu’il n’y a plus d’erreur, redémarrez le service principal de Buildbot en tapant:

sudo systemctl restart buildbot-master

Vérifiez si l’opération a réussi en tapant:

sudo systemctl status buildbot-master
Output● buildbot-master.service - BuildBot master service
  Loaded: loaded (/etc/systemd/system/buildbot-master.service; enabled; vendor preset: enabled)
   since Tue 2017-06-27 19:24:07 UTC; 2s ago
Main PID: 8298 (buildbot)
   Tasks: 2
  Memory: 51.7M
     CPU: 1.782s
  CGroup: /system.slice/buildbot-master.service
          └─8298 /usr/bin/python /usr/local/bin/buildbot start --nodaemon

Jun 27 19:24:07 bb5 systemd[1]: Started BuildBot master service

Si le service a pu redémarrer avec succès, il sera marqué comme actif.

Créer un Webhook GitHub dans le référentiel d’exemples

Maintenant que Buildbot est configuré avec un point de terminaison Web pour accepter les publications GitHub Webhook, nous pouvons configurer un Webhook pour notre fork.

Dans votre navigateur Web, accédez à votre branche du référentiel de projet exemple:

https://github.com//hello_hapi

Cliquez sur l’onglet * Paramètres * pour afficher les paramètres du projet. Dans le menu de gauche de la page des paramètres, cliquez sur * Webhooks * (GitHub peut vous demander de ressaisir votre mot de passe pendant ce processus pour confirmer votre identité):

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/webhooks_initial_page.png [page initiale de GitHub webhooks]

Cliquez sur le bouton * Ajouter un Webhook * sur le côté droit pour ajouter un nouveau Webhook.

La page qui suit contient un formulaire pour définir votre Webhook. Dans le champ * Payload URL *, ajoutez l’URL du noeud final de changement de connexion GitHub de votre projet. Ceci est construit en spécifiant le protocole + https: // +, suivi du nom de domaine de votre maître Buildbot, suivi de + / change_hook / github +.

Laissez le type de contenu défini sur + application / x-www-form-urlencoded +. Dans le champ * Secret *, entrez la phrase secrète que vous avez choisie dans votre fichier de configuration principal Buildbot. Vous pouvez laisser le déclencheur «Juste l’événement push» sélectionné et cocher la case «Actif»:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/webhooks_form.png [formulaire pour les webhooks GitHub]

Lorsque vous avez terminé, cliquez sur le bouton * Ajouter un Webhook *.

Vous serez redirigé vers l’index Webhooks du projet, où sera affiché votre nouveau Webhook. Si vous actualisez plusieurs fois, une icône en forme de coche verte doit apparaître à côté de votre lien Web pour indiquer qu’un message a été transmis avec succès:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/webhooks_success_icon.png [Icône de réussite GitHub webhook]

Si vous voyez plutôt un X rouge, cliquez à nouveau sur le Webhook, puis faites défiler jusqu’à la section * Livraisons récentes *. Plus d’informations sur ce qui s’est mal passé sont disponibles si vous cliquez sur la livraison ayant échoué.

Tester le Webhook

Maintenant que notre Webhook est en place, nous pouvons effectuer des tests pour nous assurer que lorsque nous apportons des modifications à notre référentiel, Buildbot est alerté, déclenche une construction dans Docker et est en mesure d’exécuter avec succès la suite de tests.

Dans la page principale de votre fork GitHub, cliquez sur le bouton * Créer un nouveau fichier * situé à gauche du bouton vert «Cloner ou télécharger»:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/create_new_file_button.png [Bouton de création d’un nouveau fichier créé par GitHub]

Sur l’écran qui suit, créez un fichier + dummy_file + et remplissez le texte:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/create_dummy_file.png [GitHub crée un fichier factice]

Cliquez sur le bouton * Valider nouveau fichier * en bas de la page lorsque vous avez terminé.

Ensuite, visitez votre interface Web Buildbot et connectez-vous si vous n’avez pas déjà été authentifié.

En fonction du temps écoulé depuis que vous avez engagé le + dummy_file + dans votre référentiel, vous pouvez voir une construction en cours ressemblant à ceci:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/in_progress_build.png [Buildbot en cours de construction]

Si la construction est déjà terminée, ce sera plutôt dans la section «constructions récentes»:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/build_complete.png [La génération de buildbot est terminée]

Le nom du constructeur que nous avons défini, «npm», est utilisé pour étiqueter la construction. Dans l’exemple, nous pouvons également voir une exécution plus ancienne du constructeur exemple de la configuration principale précédente.

Indépendamment de la progression, cliquez sur le lien du nom du constructeur et du numéro de construction pour accéder à la page des détails de la construction. Cette vue contient des informations sur la construction effectuée. Chaque étape que nous avons ajoutée à la fabrique de construction sera affichée dans sa propre section:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/build_details_view.png [Affichage des détails de la génération Buildbot]

Si vous cliquez sur une étape, le résultat de la commande sera affiché. Cela peut aider au débogage en cas de problème:

image: https: //assets.digitalocean.com/articles/buildbot_usage_1604/build_step_output.png [Résultat de l’étape de génération Buildbot]

Dans la sortie ci-dessus, nous pouvons vérifier que Buildbot a exécuté les trois tests de notre suite de tests avec succès.

Si la construction ne s’est pas terminée correctement, vous pouvez également vérifier les autres onglets de la page des détails de la construction, ainsi que le fichier + / home / buildbot / master / twistd.log +.

Ajuster les services Buildbot

Avant de terminer, nous devrions apporter quelques modifications à nos services Buildbot.

Actuellement, nous avons un service + buildbot-worker + défini pour un ouvrier que nous n’utilisons plus (notre ouvrier Docker est démarré automatiquement si nécessaire). Nous devrions arrêter et désactiver notre vieux travailleur.

Pour arrêter le service en cours et empêcher son démarrage au démarrage, tapez:

sudo systemctl stop buildbot-worker
sudo systemctl disable buildbot-worker
OutputRemoved symlink /etc/systemd/system/buildbot-master.service.wants/buildbot-worker.service.

La sortie ci-dessus indique que le poste de travail ne sera pas démarré au prochain démarrage. Pour vérifier que le service ne fonctionne plus, tapez:

sudo systemctl status buildbot-worker
Output● buildbot-worker.service - BuildBot worker service
  Loaded: loaded (/etc/systemd/system/buildbot-worker.service; disabled; vendor preset: enabled)


Jun 27 21:12:48 bb6 systemd[1]: Started BuildBot worker service.
Jun 27 21:55:51 bb6 systemd[1]: Stopping BuildBot worker service...
Jun 27 21:55:51 bb6 systemd[1]: Stopped BuildBot worker service.

La dernière chose à faire est d’établir une dépendance souple entre notre service principal Buildbot et le démon Docker. Etant donné que le service principal Buildbot ne pourra pas provisionner de nouveaux travailleurs sans Docker, nous devrions définir cette exigence.

Ouvrez le fichier + buildbot-master.service + dans le répertoire + / etc / systemd / system + pour ajuster le fichier de service:

sudo nano /etc/systemd/system/buildbot-master.service

Dans la section + [Unit] +, ajoutez + docker.service à la directive` + After` après l’élément + network.target. Ajoutez une directive + Wants A supplémentaire qui nomme également` + docker.service`. + Wants + établit une dépendance logicielle tandis que la directive + After + établit l’ordre de départ:

/etc/systemd/system/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

[Install]
WantedBy=multi-user.target

Enregistrez et fermez le fichier lorsque vous avez terminé.

Rechargez le démon systemd et le service pour appliquer la configuration immédiatement:

sudo systemctl daemon-reload
sudo systemctl restart buildbot-master

Le processus principal de Buildbot doit maintenant être lancé après la disponibilité de Docker.

Conclusion

Dans ce tutoriel, nous avons configuré Buildbot pour écouter les modifications apportées à un référentiel GitHub à l’aide de webhooks. Quand une modification est reçue, Buildbot démarre un conteneur basé sur une image Docker personnalisée pour tester le nouveau commit. L’image Docker contient une instance de travail Buildbot ainsi que les dépendances nécessaires pour tester notre code de projet. Cela permet à Buildbot de démarrer dynamiquement les travailleurs Buildbot selon les besoins chaque fois qu’une modification est apportée au référentiel.

Related