Si j’ai bien compris, le problème est que les binaires ont été compilés avec la version 3.4.21 de la lib gcc. Est-ce qu’il faut que la compilation soit faite avec un niveau inférieur ? Ou est-ce qu’il faut suggérer aux personnes rencontrant le même problème de mettre à jour leur lib gcc ? Quel est l’âge de la 3.4.21 ?
@elois, peux-tu regarder quelle version est sur ta machine ?
Oui, pour une plus large compatibilité, il me semble qu’il faut une glibc la plus ancienne possible ! (Mais ça ne garantit pas un fonctionnement à tout les coups)
EDIT : sur Mastodon, aeris avait recommandé un système de build dédié à debian. J’ai oublié le nom…
@sveyret bon j’ai toujours le même problème avec un build sous ubuntu trusty, le problème viens bien de docker je pense, j’ai trouver une piste ici, qu’en pense tu ?
EDIT : Le fichier .dockerignore c’est au niveau de l’image docker ou du dépot duniter qu’il faut le déclarer ?
Il y en a peut-etre un qui se créer lors de la construction de l’image, vu qu’on installe du yarn du nvm et compagnie, je fais un test si ça se trouve ça fonctionnera
J’ai supprimer l’ancien runner et en ai créer un nouveau avec les memes tag AVANT de pusher sur le dépot duniter donc je ne vois pas comment se serait possible.
J’ai également supprimer l’ancienne image sur le serveur redshift donc ça aurait planté, sauf si gitlab garde l’entièreté de l’image en cache mais je n’y crois pas.
Le runner doit faire un docker pull pour vérifier s’il n’y a pas une image Docker plus récente. Ce qu’il faut, c’est surtout s’assurer que l’image basée sur la version 16.04 a bien été supprimée sur docker-hub et sur le dépôt local.
Using Docker executor with image duniter/release-builder:v1.0.0 …
gitlab ci s’obstine a utiliser l’ancienne version de l’image, j’ai du la supprmier juste après le lancement du job, maintenant si je retry ça échoue
EDIT : bon j’ai supprimer et récréer le runner 2 fois rien a faire gitlab s’obstine a conserver une ancienne image il doit y avoir un système de cache a vider quelque part …
EDIT2: il n’y a aucun cache, c’est dans le fichier gitlab-ci que le builder tag est explicité et doit etre donc mis à jours, je n’avais pas vu !
Il suffit de télécharger et décompresser l’archive zip puis d’installer le paquet deb de votre choix (server ou desktop)
EDIT : Ça semble bien fonctionner cette release, mon noeud de test a remonter ses 7000 blocs de retard sans sync !!! (pas mis en marche depuis avant les fêtes).
@sveyret@cgeek Je me suis permis de réorganiser tout çà et d’intégrer les méthodes de @florck pour la publication des releases, il ne reste plus qu’a tester en pushant un tag bidon. Je vais attendre l’aval de @sveyret avant de tester ça.
@sveyret j’ai renommer les job de build en release et j’ai créer un nouveau job build qui s’assure simplement que duniter transpile correctement. Aussi j’ai placer les tests en amont de sorte qui si les tests ne passent pas alors les releases ne sont pas buildés, ça évitera de faire suer le serveur de CI a chaque commit pendant la dev d’une feature (il suffira au dev de casser un test puis de le réparer lorsqu’il décidera que c’est le moment de tester un paquets deb).
J’ai fait de nombreux tests en manuel et sur une installation gitlab personnelle, donc je suis assez rassuré de ce côté là. Ma seule inquiétude était au niveau des binaires générés que tu as testé de ton côté. Donc pour moi, tu peux fusionner les ressources dans la branche 1.6 et créer un tag de test.
Je pense faire l’inverse, pusher un tag bidon et si tout fonctionne bien merger après, car la partie déploiement des releases par tag n’a jamais été testée, j’ai juste copier les script de @florck et il y a peut etre des choses a ajuster
@elois, j’ai vu que tu avais créé un tag pour tester, mais la création de paquets Debian exige que le numéro de version commence par un chiffre. C’est pour cela que ça a échoué. Du coup, je pense que v1.6-TEST pourrait fonctionner.
Placer des tests en amont pour ne pas builder en cas d’échec, oui ça me semble bien.
Par contre casser exprès un test pour éviter que des livrables soient buildés, je pense qu’il vaudrait mieux faire autrement. Il me semble d’ailleurs qu’on peut déclencher manuellement un build ciblé si l’on veut, ça ne te dit rien ? Ce qui permettrait de dire manuellement à GitLab “génère des livrables” sans spécialement faire de tag.
