Il faudrait nous indiquer la manière dont est tenté cet import.
Pour mémoire, l’import Git manuel nominal doit se faire de la manière suivante:
créer le module avec les settings Git => au save le repo Git est cloné et est consultable via le bouton “Repository Git”
cliquer sur le bouton “Importer le module” => l’import se fait alors depuis le repo cloné
Pour vérifier qu’il n’y aurait pas éventuellement des pb de “tuyauterie” il faut s’assurer que le clone de l’étape 1) s’est bien passé avant de faire l’import de l’étape 2)
Nous n’avons pas connaissance d’un pb au niveau de l’import de modules via Git. Il y a donc forcément quelque chose de particulier ici :
Soit un pb de mode opératoire => à priori c’est bon (parfois ça peut aider de forcer la suppression du repo Git cloné via le bouton “Delete” de la page “Repository Git” du module, par exemple si ce clonage ne s’est pas bien passé précédemment)
Soit un pb de “tuyauterie” => le repo Git ne se clone pas ou pas correctement au save => que voit on sur la page “Repository Git” une fois le module enregistré ?
Soit un pb dans le contenu du repo Git lui même => à quoi ressemble l’arborescence du repo Git cloné localement (en dehors de Simplicité) ?
Etc.
Sans éléments contextuels c’est compliqué pour nous d’investiguer…
je veux importer 2 modules, modifiés ces derniers jours. les 2 imports me renvoient les mm erreurs.
j’ai aussi importé un module non modifié ces derniers jours et l’import a fonctionné.
je viens de faire les tests suivant :
j’ai modifié un script dans un module, exporté ce module en JSON (sans passer par GIT), en JSON éclaté. Puis choisi le fichier téléchargé et importé ce fichier sur l’environnement de recette => import OK
J’ai comité ce module sur GIT via simplicité Repository Git. Puis, sur l’environnement de recette, j’importe via la paramétrage de GIT => import KO
il y a donc bien un pb entre avec le dépot et l’import sur Git.
OK peut on voir comment est structuré le repo externe du module vs les settings Git d’import ?
Ca rejoint mon point sur le clone local => je voudrais voir à quoi ressemble l’arborescence de ce repo externe. Car si ça ne matche pas l’arborescence attendue par Simplicité (ex: si il y a un 1er niveau de répertoire) ça n’ira pas.
Pour commencer, serait il possible de tester en zappant ce repo externe et en faisant pointer les settings Git directement sur le repo du module exposé par l’instance de dev ?
effectivement, je vois que le fichier json n’est pas à la racine.
alors que pour les modules que nous n’avons pas comité récemment, il est bien à la racine.
exemple de repo git pour lequel l’import ne fonctionne pas :
OK je reproduis un symptôme similaire en commitant un module en mode JSON éclaté et en l’important sur une autre instance via Git (dans mon cas je fais pointer les settings directement sur l’autre instance)
Pas de pb avec le format XML mono fichier
Je vais retester avec les autres formats XML eclaté et JSON mono fichier.
Le mode JSON éclaté va de toute façon évoluer car il induit des pbs de taille max des paths avec ZIP et sous Windows (260 caractères max). Cf. 5.2 GIT clone file too long - #12 by Francois.
On va analyser le pb dans le cas JSON éclaté via Git (sachant qu’il ne se produit pas avec le tar.gz du module dans ce format)
En attendant le mieux est d’utiliser temporairement un des autres formats:
Le classique XML mono fichier
Le JSON mono fichier
Le XML éclaté (celui-ci n’est pas arborescent donc ne pose pas de pb de taille de paths)
J’ai vérifié ces 3 formats ne posent pas de pb avec le module de la démo mais au choix il vaut mieux opter pour l’un des deux premiers car je crois qu’il y a un ticket en cours sur le format XML éclaté.
Il y avait bien un lien avec la limitation de la taille des paths dans un ZIP => l’import Git passe en fait par une reconstruction à la volée d’un ZIP classique XML mono fichier or celui-ci ne se construisait pas bien dans le cas de paths trop longs qu’on trouve parfois dans un module JSON explosé (ça doit être le cas avec votre module).
On a revu cette partie en utilisant une archive tar.gz plutôt que ZIP, ce sera livré en 5.2.31
Ce qui a dû changer sur ce module entre le moment où il s’importait encore te le moment où il ne s’importait plus c’est que de nouveaux éléments de paramétrage ont été ajoutés et qu’ils on induits une arborescence JSON éclatée avec des paths dépassant la limite du ZIP.
L’utilisation par un format d’archive tar.gz dans la “mécanique” d’import Git a levé cette contrainte liée au format ZIP.
Attention: quand on travaille sur Windows, il y a la même limite sur les paths longs au niveau du file system. Cf. cette discussion: 5.2 GIT clone file too long => Windows et le format JSON éclaté ne font donc, à date, pas bon ménage…
Pour mémoire, le format JSON éclaté n’a d’intérêt que dans des contextes projets où il y a des modifications concurrentes de paramétrage très fréquentes qu’il faut pouvoir plus facilement merger le plus automatiquement possible en dehors de Simplicité. Si on est pas dans ce genre de contexte, il vaut mieux utiliser le format Git/ZIP XML mono fichier qui sera beaucoup plus rapide à exporter/importer.
