Je pense que les images Docker n’installent pas cette dépendance.
Pour savoir quelle image Docker est utilisée pour construire le build, je vais la dessus, et je ne trouve plein de dépôt relatifs au build. Si quelqu’un veut bien m’aiguiller ou faire le ménage entre :
Je t’aurais bien aiguillé, mais je ne sais pas du tout comment installer cette fichue dépendance python ! Ce ne devrait pourtant pas être compliqué, je suppose.
Comme indiqué dans le .gitlab-ci.yml le job de prerelease utilise l’image docker tensorflow/tensorflow:latest-py3 du docker hub. Ce n’est pas une image a nous.
D’ailleurs cette étape qui fail ne concerne pas du tout le build mais uniquement la génération automatique de la page wiki avec les liens vers les artifacts qui eux ont déjà été générés dans les job d’avant. Donc au pire la page wiki peut très bien etre rédigée a la main
EDIT: bref, le problème viens juste du fait que l’image tensorflow/tensorflow:latest-py3 n’inclus plus jinja2, donc soit faut trouver une autre image python soit créer la notre.
Ça créé une release test.
J’ai tenté de rajouter un tag, mais, ça a également fait une release test.
Le problème qu’on rencontre avec jinja2 n’arrive que sur la construction du paquet en prerelease ou release.
Comment lance-t-on une release de ce type ?
Tu as su contourner le problème pour la 1.7.14 ? Comment as-tu fait comment ?
Elles servent à quoi les étapes prerelease et release ?
Publient-elles automatiquement la release dans la section tag de GitLab ? Ou, font-telle autres choses ?
La prerelease créer la page dans le Wiki GitLab. Et la release la modifie, il me semble. Il suffit de lire le fichier releaser.py dans les sources de Duniter.
Oui je confirme. Le job release va juste modifié le wiki pour tagger la version en “release”, le but était d’avoir un truc similaire au “latest” de github
