Ce post s’apparente à un How-to sur l’intégration continue des packages d’applications à l’usage des packageurs.
L’intégration continue consiste à tester systématiquement le code lorsqu’il est modifié pour vérifier que les modifications n’entraînent pas de régression.
Les tests d’applications peuvent être particulièrement fastidieux, en raison des nombreux tests à effectuer. Pour pallier ce problème, un outil de test unitaire a été développé, Package check.
Afin d’automatiser l’usage de Package check, ce topic propose de l’intégrer à Jenkins afin de lancer automatiquement des tests complets lorsque des modifications sont faites sur le code.
Jenkins dispose d’un package communautaire pour Yunohost.
Mise en place de Package check
Après l’installation de Jenkins, il est nécessaire d’installer les scripts de CI pour Package check.
Ceci se fera très simplement.
Téléchargez l’ensemble de script dans le dossier de votre choix:
git clone https://github.com/YunoHost/CI_package_check
Attention, si vous utilisiez déjà Package check, le conteneur doit être préalablement détruit avec le script lxc_remove.sh.
Puis exécutez le script de build:
CI_package_check/build_CI.sh
Ce script créer les fichiers nécessaires dans le dossier, met en place un cron qui surveillera les tâches à exécuter et télécharge Package check.
Après le téléchargement de Package check, le conteneur LXC de test sera automatiquement créé et configuré par le script lxc_build. Ce script installera lxc, créera le conteneur et configurera un pont réseau pour celui-ci.
Package check est désormais prêt à être utilisé par Jenkins comme outil de build.
Configuration des “jobs” sur Jenkins.
Nous dissocieront 2 types de jobs Jenkins:
- Un dépôt d’application github, qui notifiera Jenkins en cas de commit. Les tests seront donc lancés dés qu’un commit est “pushé”.
- Un dossier local, analysé régulièrement à la recherche d’une modification. Les tests seront lancés si une modification est détectée dans le dossier.
Dépôt Github
Le job Github sera affecté à un dépôt d’application et lancera des tests à chaque commit. Cela permettra de s’assurer que l’application reste fonctionnelle pour les utilisateurs.
- Pour commencer on créer un projet free-style
- Dans Gestion de code source, on sélectionne Git et on renseigne Repository URL avec l’adresse du dépôt.
- Dans Ce qui déclenche le build, on sélectionne
- Build when a change is pushed to GitHub. C’est donc Github qui enverra les notifications à Jenkins.
-
Construire périodiquement, pour forcer des tests à intervalles réguliers. Afin de s’assurer que le package reste fonctionnel malgré les évolutions de Yunohost.
Je propose par défaut 2 tests par mois.
# 2 fois par mois
0 5 1,15 * *
- Dans Environnements de Build, on sélectionne Color ANSI Console Output pour améliorer la lisibilité de la console et donc des résultats détaillés des tests.
- Et enfin dans Build, on ajoute une étape, Exécuter un script shell qui contiendra l’appel à Package check.
/CHEMIN/ABSOLU/DU/SCRIPT/CI_package_check/analyseCI.sh DEPÔT_GIT "$JOB_NAME"
Attention, Jenkins doit impérativement utiliser le script analyseCI.sh
Configuration du webhook sur Github
Pour que Github soit en mesure de signifier à Jenkins un commit sur un dépôt, il est nécessaire de configurer un “webhook”.
Pour cela, sur le dépôt à configurer:
- Se rendre dans l’onglet Settings puis Webhooks
- Ajoutez un webhook
- Renseignez Payload URL avec l’adresse de contact de votre jenkins. Par défaut:
https://domain.tld/jenkins/github-webhook/ - Gardez le Content type en application/json
- Et laissez Just the push event. pour être notifié uniquement des commits et pull request mergés.
- Après validation, Github envoie une première notification à Jenkins pour vérifier la bonne communication. Cette notification ne déclenche aucun test.
- Vérifiez sur le webhook qu’il communique correctement avec votre Jenkins.
Dossier local
Le job sur le dossier local permet de tester régulièrement les modifications sur un package avant de l’envoyer sur Github. Cela permet de vérifier l’absence de régression sur un package avant de le rendre public.
- On commence de la même manière avec un projet free-style
- Dans Gestion de code source, on sélectionne Aucune.
- Dans Ce qui déclenche le build, on sélectionne [FSTrigger] - Monitor folder et on renseigne Path avec le chemin absolu du dossier à tester.
Je propose par défaut 1 vérification par heure.
# Toutes les heures.
0 */1 * * *
- Dans Environnements de Build, on sélectionne Color ANSI Console Output pour améliorer la lisibilité de la console et donc des résultats détaillés des tests.
- Et dans Build, on ajoute une étape, Exécuter un script shell qui contiendra l’appel à Package check.
/CHEMIN/ABSOLU/DU/SCRIPT/CI_package_check/analyseCI.sh "/CHEMIN/ABSOLU/DU/DOSSIER/A/TESTER" "$JOB_NAME"
Attention, Jenkins doit impérativement utiliser le script analyseCI.sh
Si le chemin contient des espaces, les guillemets sont indispensables. Si ils sont absents, une erreur sera renvoyée.
##Notes
En raison du fonctionnement parallèle des scripts de CI pour Package check, il est à noter que l’arrêt d’une tâche sur Jenkins n’arrête pas l’exécution de Package check.
L’arrêt d’une tâche ne fera que stopper le script analyseCI.sh
Pour arrêter également Package check, il est nécessaire de tuer son processus ou celui du script pcheckCI.sh et d’utiliser le script lxc_stop.sh pour arrêter le conteneur LXC.
Si la procédure devait se répéter, je verrais pour intégrer l’arrêt du processus dans le script
lxc_stop.sh…
Toutefois, afin d’éviter de bloquer le serveur, les scripts intègre un timeout, de 3 heures par défaut, qui arrêtera l’exécution de Package check si il est resté bloqué. Ceci afin de permettre une autonomie de l’ensemble.
Logs
Si nécessaire, vous trouverez plusieurs logs ayant différentes fonctions.
-
CI_package_check/pcheckCI.log: C’est le log général de CI pour Package check. Il contient toutes l’activité du script
pcheckCI.sh, donc tous les appels à Package check. - CI_package_check/logs/: Contient les logs de chaque application testée. Soit le résultat des tests de Package check et le log complet de Yunohost pour chacun des tests.
- CI_package_check/package_check/upgrade.log: Contient le log de mise à jour automatique du conteneur LXC. Le conteneur est mis à jour automatiquement chaque nuit.