Accueil > Gazette > Vie du blog > SPIP > le Spam de l’Empaqueteur

le Spam de l’Empaqueteur

lundi 5 mars 2018, par Le concombre masqué

Les abonnées de la liste spip-zone auront vu passer cet hiver, une jolie collection de mails ayant pour titre « Empaqueteur » arguant d’une erreur bien difficile à interpréter.

L’Empaqueteur, c’est le robot qui fabrique les fichiers ZIP que votre SPIP téléchargera pour installer un plugin sur votre site. Et ce robot, pour fabriquer ces paquets, s’appuie sur une seule source, le dépôt SVN de la Zone (qui, au passage, fête ses 13 ans ces jours-ci).

Ce robot vit sur une machine et exécute sans relâche les mêmes tâches, libérant ainsi les humains d’un labeur ingrat. Il a peut-être vécu sur d’autres machines dans le passé, nous ne saurions le dire avec précision, mais on peut dire qu’il fait son travail avec la même abnégation depuis 8 ou 9 ans et ceci presque sans avoir eu besoin d’évoluer.

Quel est son ADN ? Comment fonctionne-t-il ? On nous l’a expliqué à ses débuts ici : Le script Smart-Paquets actuel

On peut donc lire le code source de l’Empaqueteur sur la Zone même.

Depuis sa naissance, il traite des fichiers texte, s’appuie sur la commande svn up pour mettre à jour des fichiers et les zipper.

Puis, il a été possible de référencer du code développé ailleurs, via un mécanisme propre à subversion, les externals. Pour faire simple, ça « virtualise » la présence d’un dépôt de code plus ou moins lointain dans la Zone, pour peu que ce dépôt sache communiquer avec SVN.

Github plaît à certains codeurs et propose une interface subversion, on peut donc relier un plugin développé sur Github à l’Empaqueteur, via un fichier texte, lui-même historisé sur la Zone, et dans lequel il faudra préciser le même type de paramètres que pour du code versionné sur la Zone. Donc 2 manips : mettre à jour la propriété svn:externals du répertoire _externals_ ET mettre à jour le fichier texte archivelist_externals.txt

Et on s’aperçoit d’un truc à propos des dépôts github, c’est que c’est beaucoup d’énergie pour bien peu de chose.

Qu’est-ce que ça fait ?

Attention, c’est technique...

Les scripts s’appuient sur une version synchronisée du dépôt spip-zone. Il ne s’agit pas d’une « simple » working copy résultant des commandes svn co, puis svn up. En fait, il y a un serveur subversion supplémentaire, qui est synchronisé avec la zone par le robot juste avant la mise à jour de sa propre working copy. Sans doute pour éviter de solliciter la Zone directement via le client svn...

Cette partie de la configuration n’est pas documentée et les scripts s’appuient sur une arborescence codée en dur (/home/smart_paquets, home/svn/repository/spip-zone, etc.).

C’est donc un peu difficile à reproduire pour tester, dépanner, et éventuellement améliorer.

Le fichier archivelist_externals.txt réunit donc la liste des zip à produire sur la base du répertoire _externals_ qui est « vide » mais qui contient des propriétés (le fameux mécanisme de « virtualisation ») qui référencent des dépôts externes, tous sur Github. Ça transforme donc, quand tout marche bien, le dépôt Git en dépôt svn avec trunk/ = master, branches/X = une branche git X et tags/v1.3.3 = le tag v1.3.3. C’est ce qu’on appelle le standard layout.

Si le fichier archivelist_externals.txt date de moins d’une heure, il fait un update du répertoire _externals_, sinon il ne fait rien rien. C’est vérifié toutes les heures:19 puis ensuite c’est la génération inconditionnelle des zip à partir de répertoire du type _externals_/github_machin/tags/v1.3.3, par exemple.

Pourquoi ça pète ?

Si le fichier archivelist_externals.txt est vieux de plus d’une heure dans la working copy du robot mais que le répertoire _externals_ n’est pas synchrone, les tags github ne seront pas reproduits et le zip basé sur un tag ne peut pas être fait, faute de fichier et ça fait une erreur qui envoie un mail, et ceci toutes les heures:19 ...

Que faut-il faire ?

Même en consultant le log de la dernière exécution, difficile de poser un diagnostic à distance.

Il faudrait peut-être vérifier la synchro du serveur intermédiaire qui sert à la production de la working copy, voire reconstruire ce dépôt, puis la working copy car manifestement, c’est la partie synchronisation spip_zone/machine de l’empaqueteur qui est en erreur. Avec ou sans mise à jour du fichier texte, le répertoire _externals_ semblent ne pas se synchroniser avec les dépôts Github.

Que peut-on en dire ?

C’est dommage. Github fabrique lui-même des zip pour chaque release. Mais comme une release, c’est un tag, le nom du zip prend ce tag comme suffixe et son dézippage créé un répertoire avec le tag comme suffixe. Du coup, on peut supposer que SVP ne saurait les exploiter en l’état, parce qu’au lieu de mettre à jour un répertoire dans plugins/ il en créerait un autre... et que c’est là, probablement, la raison qui a poussé à mettre en place une telle architecture.


Bon, ce serait troller de dire que composer sait faire ça. Mais si SVP savait dézipper les archives github comme SPIP en a besoin, il « suffirait » de référencer le zip produit sur github dans la mécanique générale de smart_paquets et/ou du référentiel XML (non détaillé dans cet article) de SVP : ça allégerait la charge de traitement, d’hébergement... et se serait moins lourd pour ceux qui font le choix de développer leurs plugins hors zone.

Messages

  • Et du coup concrètement on fait quoi dans ce genre de cas en décalage ?

  • Dans l’urgence, on contacte une personne ayant accès à la machine hôte de l’empaqueteur pour faire les vérifications et éventuelles réparations suggérées. Ou tout autre diagnostique... après tout, il est aussi possible que ça ne marche pas tout à fait comme dans l’hypothèse de ce billet.

  • On saurait faire ça avec composer ?
    Intéressant, ce serait peut être une idée pour moderniser tout ce bazar et mettre un pied dedans.

  • Merci pour ce point technique mais qui permet de comprendre ce qui se passe, quelle transparence ! :)

    Quand vous dîtes « et que c’est là, probablement, la raison qui a poussé à mettre en place une telle architecture » ou « Cette partie de la configuration n’est pas documentée », c’est parce que personne ne sait plus comment ça marche ?

  • @nicod_ : Pour préciser, composer sait récupérer des ZIP et déballer les fichiers dans des répertoires qu’il nomme lui-même. La remarque n’était pas forcément (mais pourquoi pas, après tout :p) d’utiliser composer dans l’immédiat, mais de modifier SVP afin qu’il choisissent lui-même le nom du répertoire. Bon, faut vérifier comment fonctionne SVP et comment sont foutus les ZIP eux-mêmes...

    @jeanmarie : ça veut dire que le concombre fait des hypothèses à partir des informations qu’il a sous les yeux (le code, les fichiers, la configuration du répertoire de la zone, le fichier de log, et la doc d’origine), sans accès à la machine hôte dont il ignore tout.

Un message, un commentaire ?

Qui êtes-vous ?
Se connecter
Votre message

Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.