Merci.
Tu as supprimé ta branche
hugo-dev ? Je peux faire sans, mais il y avait du code modifié et non mergé.
edit : ah non c'est sur master. Merci.
Merci.
Tu as supprimé ta branche
hugo-dev ? Je peux faire sans, mais il y avait du code modifié et non mergé.
edit : ah non c'est sur master. Merci.
Je sèche un peu sur le job de CI qui doit appeler le srtool. En fait la CI ne monte pas le volume sur cette instruction :
docker run -i --rm -e PACKAGE=gdev-runtime -e RUNTIME_DIR=runtime/gdev -v "$(pwd):/build" paritytech/srtool:1.62.0 build --app --json -cM
Le résultat est visible sur ce job : create_release (#113177) · Jobs · nodes / rust / Duniter v2S · GitLab
Le srtool fini par me dire "No such file or directory", ce qui est logique.
C'est une histoire de Docker mais ça me dépasse, @immae as-tu une idée ? Vu que je passe par Kepler sur ce job. J'ai pourtant bien vu que le mode "privileged" était utilisé dans la conf Nix.
A priori la solution c'est de monter le path de l'hôte (Kepler) plutôt que la path dans le conteneur du job dans l'instruction ci-dessus. Mais je ne sais pas comment l'obtenir.
Y'a-t-il une raison particulière pour laquelle tu fais du dind (Docker in Docker) ? Ça complexifie la tâche.
Pourquoi ne pas spécifier l'image
paritytech/srtool:1.62.0 pour ce job ?
Le contenu du dépôt duniter-v2s est automatiquement "monté" et devient accessible dans l'image
paritytech/srtool et tu pourrais lancer la commande
srtools sur le dépôt duniter-v2s.
Exemple à peu près :
create_release: stage: test_deploy image: paritytech/srtool:1.62.0 rules: - when: always variables: # pas sûr que ça donne des variables d'environement, sinon utiliser les exports ci-dessous PACKAGE: "gdev-runtime" RUNTIME_DIR: "runtime/gdev" script: - export PACKAGE=gdev-runtime; export RUNTIME_DIR=runtime/gdev; srtool build --app --json -cM artifacts: name: "Artifact 1" paths: - resources/ - runtime/gdev/target/srtool/release/wbuild/gdev-runtime/ expire_in: 1 day tags: - kepler
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
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 Genesis
history.json: un fichier d'historique des transactions
Si 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