Intégration continue sur les packages d'applications yunohost

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.
3 Likes

Est ce que cela signifie que les applications “officielles” pourront être plus rapidement plus nombreuses ?

Dans une certaine mesure oui, si nous pouvons les tester plus simplement, d’avantage d’applications pourront devenir officielles.
Mais ce n’est pas le seul paramètre qui entre en compte pour qu’une application devienne officielle.

Toutefois, pour le moment il est question d’intégration continue à l’usage des packageurs. C’est donc avant tout un outil permettant aux packageurs de vérifier l’état de leur applications.
Nous réfléchissons toutefois à étendre cela à l’ensemble des applications, afin que chaque utilisateurs puissent prendre connaissance de l’état d’une application avant de l’installer.

1 Like

Avis aux utilisateurs des scripts CI_package_check, une importante mise à jour vient d’être faite.
Apportant en particulier la possibilité d’effectuer des tests sur des machines distantes pour tester sous différentes architectures processeurs.

Toutefois, cette mise à jour ajoute aussi l’usage d’un fichiers de configuration pour isoler les config utilisateur et permettre de mettre à jour simplement avec git pull.
En l’absence de ce fichier de config, les scripts ne fonctionneront pas.

Il est donc nécessaire de créer le fichier de config en dupliquant le fichier config.modele en config

Merci, ça marche pour moi :

J’ai du faire les choses suivantes pour que cela fonctionne sur mon setup :

  • git clone CI_package_check dans le dossier /home (ou en tout cas pas dans /root)
  • chown -R jenkins:www-data /home/CI_package_check