Ah mais oui Moul, bien vu ! Je vais essayer 
edit : yes, ça a fonctionné 
merci, je poursuis !
edit 2 : hop pour les plus curieux, release produite par la CI avec le Runtime ĞDev (et le fichier de sortie de srtool, pas indispensable mais peut être utile pour contrôle). Cette release sera écrasée dans les prochains jours avec les éléments manquants, mais c’est pour montrer que les choses avancent.
J’en suis rendu à reprendre cette partie du travail pour la mettre dans le pipeline commun (méthode gen_genesis_data qui produit un format pivot) côté duniter-v2s.
Te souviens-tu du niveau d’avancement que tu avais atteint sur cette partie ? J’ai un gros travail de refactoring car effectivement, les Genesis ĞDev et ĞTest n’étaient vraiment pas formés de la même façon. Savoir où tu en étais m’aiderais à savoir si je dois être minutieux ou si avancer sur les grandes lignes suffirait.
Voici ce que je note côté py-g1-migrator :
Et à part ça, il faut tenir compte de la sortie des print avec un “
” pour les incohérences détectées par le migrator.
J’ai notamment fait le tour des sujets qui parlent de ça :
Côté Duniter-v2s, je n’ai pas trop documenté à part dans les commentaires du code parce que je m’adaptais à ce que je faisais sortir du migrator. Mais de mémoire et en regardant le code :
Et donc pour répondre à la question, je dirais que le niveau d’avancement côté gtest est assez poussé, il faut être un peu minutieux dans les refactoring et lire les commentaires dans le code. Par contre côté gdev il faut pas hésiter à tailler dans le gras, j’ai quasiment pas touché à ce qu’avait fait elois pour éviter de casser les tests qui étaient basés sur cette manière de parser le genesis, mais le but de la factorisation étant de rapprocher les tests des conditions réelles, c’est le moment de casser des trucs.
Merci pour cette réponse très complète.
Je vais donc plutôt partir du code présent dans le fichier gtest_genesis, tout en le faisant rentrer dans le format pivot, puis j’adapterai ce qui tourne autour de la ĞDev. Il y a quand même beaucoup des similitudes, ça devrait bien se passer.
Puis ce sera travail itératif d’incorporation de toutes les règles que tu viens de mentionner, et du transfert des règles qui étaient dans py-g1-migrator vers Duniter afin de centraliser les contrôles auprès du code qui fait foi (le Runtime).
Je ne me rendais pas compte à quel point il restait du travail sur cette partie migration.
Pour suivi : j’ai pratiquement terminé les développements, il me reste des finitions.
Restera ensuite une revue de code à effecuter par tuxmain et/ou Hugo, puis nous pourrons tenter de relancer une ĞDev. A mon avis, tout cela sous 15j.
Traité : est défini dans le fichier de conf de chaque monnaie (gdev.json, gtest.json).
Je considère que c’est fait, au sens où il n’y a – pour l’instant – aucune monnaie à transférer vers la Trésorerie selon moi. Si cela devait toutefois changer, il suffirait d’adapter la fonction gen_genesis_data.
N’est plus nécessaire : les comptes Ğ1v1 sont importées bruts (clé publique Ed25519) car Substrate ne fait qu’extraire les clés publiques et ne contrôle pas les adresses pour le Genesis.
Fait, on voit que ce n’est pas le cas. Reste à voir d’où provient ce delta.
La conversion se fait côté Substrate, et un test couvre ce cas de figure.
Les seules sorties qui méritent encore de l’attention selon moi sont :
⚠️ Pseudo1 → Llorens cert expired between export and start
⚠️ Pseudo2 has received only 1 certs, disabling it
Je vais voir pour les déplacer côté Duniter.
OK.
Par conséquent, reste à faire :
Ne pas filtrer les certifications ou identités côté py-g1-migrator mais côté Duniter
s’assurer que la trésorerie ne crée pas de monnaie au genesis (elle doit être mise à existential deposit minimum, donc si elle est à zéro de la monnaie est ajoutée)
s’assurer qu’il y tous les check au genesis nécessaires à ne pas avoir d’incohérence de storage
Adapter py-g1-migrator pour la migration Ğ1
What’s needed to start a ĞTest network
Incohérence dans les données? – certifications expirées
V2S: Ğ1 data migration (g1-migrator)
Date de création du DU
Quantité de monnaie sur Duniter / Total issuance vs monetary mass
g1-migrator ==> seulement le sujet V2S: smooth gradual migration (clients and indexers side)
Pas sûr que je traite tout dans la même MR, nous verrons.
Il me reste deux sujets :
Bref pour moi la tâche arrive à sa fin, je vais peaufiner les 2-3 TODOs que j’ai laissé dans le code, nettoyer le fichier .gitlab-ci.yml puis tester tout cela de bout en bout, créer une release et lancer une ĞDev locale.
Vous pouvez déjà commencer à inspecter la MR!182 si vous le souhaitez.
Pour la création d’un Genesis pour l’indexer, il faut extraire de la v1 toutes les transactions avec le message, toutes les certifications des membres… et je me souviens plus. Il faut que je regarde ce qu’avait fait @poka.
J’ai regardé dans le indexer.json.zip, il n’y a pas les certifications ?
Sinon, merci à toi ! Génial de voir que ça avance
A regarder py-g1-migrator, je dirais que l’indexer mange deux fichiers :
gdev.json : un fichier de Genesishistory.json : un fichier d’historique des transactionsSi dans le champ certs_by_receiver, qui associe à l’index du receveur une map issuer → dateExpiration. Mais on peut facilement lui donner une autre tête, en mettant les pseudonymes, les clés publiques ou encore les adresses. A toi de me dire
Ah, je n’avais pas vu le champ !
Oui, l’indexer a besoin de ces 2 fichiers. Les derniers en date que l’on a utilisés sont là :
OK, je vais reprendre leur format dans ce cas. Si je mets tout dans un seul fichier indexer-gdev.json par exemple, ça te va aussi ?
Oui, carrément ! Je m’adapte
Petit inconvénient de forcer ceci dans le format du genesis : on ne bénéficie plus de la checksum intégrée à l’adresse. Embêtant pour les fichiers de test dans lesquels c’est pratique de mettre les adresses plutôt que les pubkeys “nues”.
Tu parles des fichiers Cucumber ?
Oui, par exemple, ou quand on veut un fichier custom de dev local avec Alice Bob et compagnie.
Dans ce cas on peut laisser les deux champs : pubkey et address, les deux étant optionnels et j’ajoute un contrôle dans gen_genesis_data pour qu’un seul des deux champ soit renseigné.
Je vais voir, j’ai encore des vérifications à faire avant de me repencher sur ce genre de cas.
Voilà une nouvelle version, qui ressemble beaucoup plus à l’ancien gdev.json avec une nouvelle entrée "transactions_history" : https://dl.cgeek.fr/indexer.json.zip
Le fichier JSON fait 85Mo 
La branche a été mergée. Petite présentation du nouveau processus de livraison que nous utiliserons pour prochainement relancer la ĞDev (700).
release/runtime-<numero>La création se réalise en créant une branche depuis master release/runtime-<numero> où <numero> est la version du Runtime. Exemple : release/runtime-700.
Une fois la branche poussée, GitLab CI crée un pipeline comme le suivant qui s’affiche et s’exécute jusqu’à l’étape bloquante create_release :
On voit ici tous les jobs impliqués, leurs liens de dépendance et ceux qui nécessitent une action manuelle symbolisée par l’icône 
.
Les dépendances sont matérialisées par les lignes grises (ou bleues au survol d’un job). Dans la capture ci-dessus je survole create_release.
Une fois lancé le job create_release, la page de release et le tag (ici runtime-700) sont créés.
La release contient les informations suivantes.
Ce sont les livrables par défaut de toute release, même si certains ne seront pas exploités.
Quoi qu’il arrive, les fichiers de Runtime seront exploités : soit pour faire un Runtime upgrade, soit pour démarrer un nouveau réseau.
gdev_runtime.compact.compressed.wasm : le Runtime ĞDevgtest_runtime.compact.compressed.wasm : le Runtime ĞTestCes fichiers ne seront utilisés que si l’on souhaite démarrer ou rebooter une monnaie. Néanmoins, en l’état actuel du développement de Duniter V2, c’est une opération que nous sommes susceptible de réaliser fréquemment donc pour l’instant ces livrables seront produits à chaque fois.
Ces fichiers sont présents dans la page de Release uniquement par soucis de transparence et de vérification. Seuls les fichiers “En sortie” seront directement exploités.
gdev.json: le fichier de configuration du Genesis pour la spec du réseau ĞDevgtest.json: le fichier de configuration du Genesis pour la spec du réseau ĞTestgdev_clients-specs.json: le fichier de configuration du Client pour la spec du réseau ĞDevgtest_clients-specs.json: le fichier de configuration du Client pour la spec du réseau ĞTestg1-data.json : le fichier de migration des données de la Ğ1 intégrées à la spécification des réseaux ĞDev et ĞTestLes fichiers de specs :
gdev-raw.json : la spécification du réseau ĞDev, résultante de gdev.json, g1-data.json et gdev_client-specs.json
gtest-raw.json : la spécification du réseau ĞTest, résultante de gtest.json, g1-data.json et gtest_client-specs.json
Les détails des deux Runtimes (bientôt trois avec la Ğ1) produits, un pour chaque réseau :
Si le Runtime doit servir à rebooter un réseau (par exemple redémarrer la ĞDev), alors il y a deux étapes supplémentaires à réaliser.
C’est une pratique courante avec Substrate : publier les chain specs avec le code source du projet.
Une commande xtask a été créé pour l’occasion. Ici, pour mettre à jours les chain specs du runtime-700, à lancer depuis la branche de release :
cargo xtask update-raw-specs runtime-700
Cette commande va télécharger les chain specs publiées dans la page de release si celles-ci existent :
Et les pousse dans le répertoire node/specs/.
Il suffit alors de commiter ces fichiers et de les pousser depuis la branche de release.
Créer ou rebooter une monnaie implique de relivrer le Client, puisque celui-ci se base sur les chain specs pour authentifier la blockchain à laquelle celui-ci va se connecter.
Une fois l’étape précédente réalisée (commiter les chain specs), la CI propose alors deux jobs permettant de builder puis publier les images Docker idoines :
gdev_docker_release_build : pour builder l’image Docker du Client ĞDevgtest_docker_release_build : pour builder l’image Docker du Client ĞTestgdev_docker_release_deploy : pour publier l’image Docker du Client ĞDevgtest_docker_release_deploy : pour publier l’image Docker du Client ĞDev