Je penses qu’il y a déjà des scripts dans /release qui font le tag, non ?
Peut-être en pre-release du coup ? Je ne penses qu’une 1.8.7-alpha serait plus sûr
En effet. Donc je reformule :
release/new_version.sh 1.8.7-rc1git push && git push --tags
Ceci autant de fois que nécessaire pour que la CI se passe bien.
Puis :
release/new_prerelease.sh 1.8.7-rc1release/set_release.sh 1.8.7-rc1 pre
Et une fois que tout est OK, on refait tout en 1.8.7 et la dernière commande devient :
release/set_release.sh 1.8.7 rel
Je suis loin d’être certain que ça marche du premier coup, mais on y croit 
1 Like
Si tu as déjà creusé le sujet il faudrait que tu écrives un test, à l’instar de block-with-transaction-revert.ts mais avec des vérifications bas niveau comme ceux présents dans sources-dal.ts et triming-dal.ts.
Vu que tu es dedans tu te rends bien compte que la charge mentale est élevée pour rentrer dans cette partie du code 
avec un test je pourrai plus facilement faire la revue. En plus cette semaine est très chargée pour moi donc je n’ai vraiment pas le temps de creuser.
En termes d’impact, nous verrons ensuite.
1 Like
Merci @cgeek pour ta réponse. Ok je vais ajouté un test.
J’ai vu ta remarque sur le ticket #1447. Je vais faire un revert, et également ajouté un test car cela ne me semble pas clair.
Du coup @Pini j’ai fait une erreur, il faudra refaire une version quand j’aurais corrigé ce point. Je te redis
@Pini, la branche release/1.8 est OK pour moi. J’attends juste une dernière confirmation de @cgeek sur le ticket #1447
En parallèle sur la branche feature/node-20, j’ai commencé une mise à jour vers nodeJS v20 et LevelDB v8 : gros chantier !! Mais ca avance : plus que quelques tests qui ne passent pas (24 sur 803).
J’ai commencé la mise à niveau des images docker duniter-ci et duniter-release, vers node 20.
Il me restera encore à mettre à niveau duniter-ui, pour qu’il fonctionne également en node20 (via nwjs 0.77)
Ensuite, je pourrais attaquer l’analyse des problèmes mémoires (s’ils n’ont pas été résolu par cette gros mise à jour).
3 Likes
Je viens de mettre à jour mon neoud 1.8-dev.
Si tu en as le temps, je veux bien que tu essaies de refaire une synchro. Éventuellement en comparant la tailles des fichiers avant et après.
On aura comme cela une idée exacte des perfs, de synchro et de resuetage BMA, car certains index étaient mal élagués au cours de la synchro. Un index plus léger peu augmenter un peu les perfs.
Bon a mon avis ça doit être négligeable quand même.
1 Like
Plus que 13 tests qui ne passent pas !
Le gros des problème étaient dus a des changements dans Micha. Notamment a la fermeture des tests.
Je ne pourrais finir que la semaine prochaine. Je dois filer .
Peux-tu me citer les fichiers qui t’intéressent ?
De tête (je suis pas chez moi) dans un répertoire level_db, les fichiers level_sindex/conditions et level_sindex/written_on (cf ce code sinon : app/lib/dal/indexDAL/leveldb/LevelDBSindex.ts · dev · nodes / typescript / duniter · GitLab)
Ok @Pini si tu veux lancer la release 1.8 je penses qu’on peut y aller. La branche release/1.8 me semble prête.
La correction du bug 1446 va éviter les fork des noeuds forgerons. Le fork a d’autant plus de chance de se produire que le bloc annulé possède de TX. Ça doit donc théoriquement augmenter l’instabilité du réseau au fur et à mesure de son utilisation 
Espérons que tout cela tiennes encore le coup quelques mois…
2 Likes
Je n’ai comparé qu’en la 1.8-dev précéddente et l’actuelle. Je ne vois pas de gain pour le répertoire leveldb/level_sindex/conditions. En revanche gain d’1/3 pour leveldb/level_sindex/written_on.
$ du -hs {old,new}/data/leveldb/level_sindex/conditions/
30M old/data/leveldb/level_sindex/conditions/
32M new/data/leveldb/level_sindex/conditions/
$ du -hs {old,new}/data/leveldb/level_sindex/written_on
27M old/data/leveldb/level_sindex/written_on
18M new/data/leveldb/level_sindex/written_on
1 Like
J’ai mis à jour mon noeud 1.8-dev si tu veux jeter un oeil. J’attends ton go puis je tente la release.
Cela correspond tout à fait aux modifications apportées. 
1 Like
Merci @cgeek pour ta validation du ticket #1447
En revanche, je ne sais pas si as tu eu le temps de regarder l’autre ticket #1446, et notamment cette ligne
Bon de toute manière @Pini je penses qu’on peut lancer une release. Go
1 Like
C’est fait. J’aurais probablement pas dû lancer le job publish car après coup je me rends compte que c’est uniquement pour les releases et pas pour les pré-releases. Le job a planté mais la v1.8.7-rc1 apparaît comme une release.
À part ça les assets sont bien là et l’image Docker a été publiée. Y’a plus qu’à tester.
1 Like
Youpi Grand merci !
Pas grave, j’ai modifié la description à la main, pour afficher “'pre-release”.
Du coup, j’en ai profité pour mettre la 1.8.6 en Release.
Je vais lancer un test.
Je suggère qu’on ne soit par trop nombreux à tester pour le moment, pour ne pas déstabiliser le réseau au cas où il reste un problème.
2 Likes
Je n’avais pas vu, je me suis un peu noyé dans les MR/tickets. Je viens de regarder et commenter le ticket #1446.
Go pour moi
3 Likes
Yes : mon nœud g1.e-is.pro (dont la synchro plantait depuis des lustres - pb de mémoire notamment) vient finir une synchro avec succès !
4 Likes
Et le noeud 1.8.7-rc1 a émis plusieurs blocs valides
Pour le moment tout baigne
5 Likes