Ce serait en effet super d’automatiser ce processus avec une CI ! Je ne m’étais pas lancé dedans pour plusieurs raisons :
- à l’époque je travaillais avec @poka et on y arrivait mieux en bidouillant des scripts exécutés avec un cron
- j’avais et ai toujours du mal avec cet outillage (Difficultés avec l'outillage)
- je ne suis pas confiant sur la CI et les GitLab runners (Contribution souhaitée : CI GitLab de Duniter v2s, Duniter indexer CI), en partie parce qu’on manque de personnes pour faire l’admin sys quand il y a un panne et que je ne sais pas faire moi même
Mais si quelqu’un se lance dedans alors je vais faire tout mon possible pour l’aider !
Oui, il y a dedans du travail de réorganisation, commentaire de code, correction de bugs à conserver. Il y a aussi des modifications spécifiques à la ĞTest comme l’adaptation au format du genesis ĞTest, notamment le nom des champs (“index, owner_key, membership_expire_on, next_cert_issuable_on, certs_received”).
Ces modifications vont de pair avec la branche hugo-gtest sur duniter-v2s. J’ai développé les deux en parallèle pour vérifier les entrées côté duniter et produire une sortie complète et cohérente côté py-g1-migrator.
Voilà pourquoi ce n’est pas mergé pour l’instant.
Et d’ailleurs, il y a aussi des modifications côté indexeur pour qu’il soit compatible avec les deux formats de genesis. (cf index-genesis-gdev.ts et index-genesis-gtest.ts dans src/services · master · nodes / duniter-indexer · GitLab).
Il faut qu’on discute de ces différences et si ça vaut le coup de le conserver, j’ai ajouté ce point à l’ordre du jour de la Visio dev -- mercredi 20 septembre 2023 -- 21h.
Il y a un todo ligne 116 à ce propos. Si je comprends bien, l’idée de faire ça est qu’on puisse télécharger le runtime depuis gitlab pour le soumettre sur la chaîne ?
Pour le reste, tout me semble ok. Et à mon avis on ne devrait rien mettre concernant les monnaie sur la branche master, et avoir une branche dédiée par réseau (gdev6, gdev7, gtest, g1). Ça éviterait de trop se mélanger les pinceaux et on pourrait utiliser le nom de branche pour générer l’image docker, par exemple duniter/duniter-v2s:gtest serait le "latest` sur le réseau gtest en cours (cf discussion Release new image with ĞDev5 chainspecs - #46 by Moul).