On peut mettre la limite où on veut, l’idée est de pouvoir éditer les données de test facilement pour les besoins des tests (exemple pour l’indexeur : Files · master · nodes / duniter-indexer · GitLab).
Mais c’est vrai que le schéma :
base de données v1
outil pour exporter les données v1 dans un format 1 (py-g1-migrator)
outil pour convertir le format 1 dans un format 2 (parsing du genesis duniter)
outil pour utiliser le format 2 (genesis builder duniter)
pourrait être simplifié.
Oui, en effet, hugo-gtest est une branche local pas très loin de hugo-dev. Je vais rebaser sur master en priorité cette semaine.
Le runtime ĞDev est différent des runtime ĞTest entre autres parce qu’il utilise duniter-test-parameters pour pouvoir changer plus facilement certains paramètres en cours de route.
J’ai rebasé hugo-dev sur master. Un détail : dans time-base UD, tuxmain a renommé “first_ud” en “ud” et ajouté “first_ud” pour la date du premier DU. J’ai donc adapté le format du genesis en fonction. Le champ que j’avais appelé first_ud_value correspond maintenant à ud et il y a un champ additionnel first_ud. Voilà une incohérence que je préfère te signaler avant que tu tombes dessus.
On voit ça dans la macro custom pallets_config! (gdev, gtest, définition), le runtime gdev utilise la pallet duniter_test_parameters plutôt que des valeurs hardcodées. Elles peuvent être modifiées avec un simple call en root et donc ne nécessitent pas un runtime upgrade pour être modifiées.
Je pense que c’est dans l’idée de ce post (Liste des paramètres (protocolaires) de Duniter-v2s) que elois a implémenté cette pallet pour faciliter la modification des paramètres en phase de test. Mais au début il n’y avait pas de README par pallet ni par runtime, je les ai ajoutés par rétro-ingénierie donc c’est peut-être pas toujours pertinent.
Est-ce que supprimer duniter_test_parameters nous soulagerait d’une complexité encombrante, faciliterait significativement les contributions et la compréhension ? Pouvoir modifier facilement certains paramètres semble utile.
Je dirais que oui c’est encombrant, indépendamment de ma tâche en cours : cela crée dans le code plusieurs sources de vérité sur la provenance de la valeur des paramètres de la monnaie (confusion, déjà observée chez @HugoTrentesaux et moi-même à nos débuts) et nous éloigne du scénario standard où ces paramètres ne sont pas modifiables (risque de non-test ou mauvais tests).
Si les paramètres sont modifiables uniquement par Runtime upgrade, alors autant se placer tout de suite dans ce cas là sauf intérêt supérieur à pouvoir les modifier à chaud. Or, d’une part nous sommes tout proche d’une GTest, d’autre part je ne vous ai jamais vu utiliser cette fonction sur la Gdev.
Oui, sans problème, et n’hésite pas à me ping dès qu’il y a quelque chose de pas clair, je suis dispo 100% du temps et souhaite limiter les frictions au maximum pour que tu puisses avancer sans encombre.
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’imageparitytech/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
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.
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 :
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
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.
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.
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.
merci, je poursuis !
” pour les incohérences détectées par le migrator.