État des lieux des différentes chaînes

La branche 125-industrialize-releases-production arrive à maturité, il est temps que je fasse le point sur les changements de chaîne et de Runtime.

Les modifications

Globalement, l’idée est 1 chaîne = 1 comportement, ce qui n’était pas toujours le cas avant.

Chaîne Runtime Etat
dev ĞDev Modifiée : désormais ne fait que générer une toile “random” de 4 membres, 3 smiths et 1 autorité. Son but : faire une toile locale pour du développement.
gdev_local ĞDev Supprimée car fait doublon avec dev.
gdev_dev ĞDev Nouveauté : c’est la gdev_live mais agrémentée d’une autorité forcée “Alice”, qui se voit attribuer les éléments nécessaire à son existence : certifications de membre, certifications de smith, etc.
gdev_live ĞDev Conservée : c’est la ĞDev “from source”, à compiler, avec les paramètres officiels de la ĞDev (représentés par le fichier resources/gdev.json) et les données de la Ğ1 (fichier g1-data.json).
gdev ĞDev Conservée : c’est la ĞDev “from binary”, pré-compilée dans un fichier specs/gdev-raw.json lui-même produit à partir d’une gdev_live au préalable.
gtest_dev ĞTest Conservée : même idée que la gdev_dev mais pour la ĞTest : c’est une gtest_live avec “Alice” comme autorité forcée.
gtest_live ĞTest Conservée : même idée que gdev_live, sauf que le fichier de paramétrage est resources/gtest.json. Les données de la Ğ1 sont aussi incorporées via le fichier g1-data.json.
gtest ĞTest Conservée : même idée que gdev : c’est la version pré-compilée de la ĞTest, basée sur le fichier specs/gtest-raw.json.
g1 Ğ1 Conservée : telle quelle pour le moment (non implémentée), mais suivra le même schéma que ĞDev et ĞTest avec son propre fichier de paramétrage.
/fichier.json Déduit du nom de fichier. Conservée : permet de construire les raw specs à partir d’une spec non-raw, et de modifier uniquement les specs du Client. Voir la documentation Substrate à ce sujet.

J’ai fait l’impasse sur les chaînes de benchmarks, mais celles-ci n’ont pas bougé.

Utilisations

Chaîne Runtime Utilisation
dev ĞDev Tester en local le Runtime avec des comptes maîtrisés (Alice, Bob, …)
gdev_dev ĞDev Manipuler la vraie ĞDev mais en gardant la maîtrise de l’autorité grâce au compte Alice.
gdev_live ĞDev La vraie ĞDev, mais réseau non lancé. C’est pour le démarrer.
gdev ĞDev La vraie ĞDev, mais réseau déjà démarré. C’est pour le rejoindre.
gtest_dev ĞTest Manipuler la vraie ĞTest mais en gardant la maîtrise de l’autorité grâce au compte Alice.
gtest_live ĞTest La vraie ĞTest, mais réseau non lancé. C’est pour le démarrer.
gtest ĞTest La vraie ĞTest, mais réseau déjà démarré. C’est pour le rejoindre.
g1 Ğ1 Sera elle aussi découpée en _dev, _live et sans suffixe.

Options

Pour toutes les chaînes suffixées _dev ou _live, il est possible de redéfinir les fichiers en entrée grâce à des variables d’environnement :

  • DUNITER_GENESIS_CONFIG : fichier qui définit les paramètres de la monnaie, typiquement le montant du DU, son premier versement, et sa 1ère réévaluation, les smiths initiaux, le comité technique et le compte qui versera les 1,00 Ğ1 initiaux à la Trésorerie.
    Pour la ĞDev, ce fichier comporte également les paramètres configurables (qui seront au contraire figés dans le Runtime pour la ĞTest et la Ğ1) comme le nombre de certifications requises pour être membre, etc.
  • DUNITER_GENESIS_DATA : fichier qui contient les données de toile de confiance initiale et des wallets. Par défaut, c’est celui présent dans resources/g1-data.json, mais dans le cas du lancement d’une nouvelle monnaie (_live) ce fichier est généré à la volée par la CI pour avoir les données les plus fraîches possibles du réseau Ğ1 propulsé par Duniter v1.

Exemple des tests End2End

Les tests Cucumber exploitent un fichier unique (soit default.json, soit wot.json pour le moment) qui agrègent à la fois le contenu de DUNITER_GENESIS_CONFIG et DUNITER_GENESIS_DATA, et lancent un nœud sur la chaîne gdev_dev. De cette façon tous les paramètres et les donnée sont connus d’avance, et l’on dispose notamment des comptes Alice, Bob et cie pour réaliser des manipulations automatisées ainsi que de l’autorité Alice pour créer des blocs.


Voilà, si vous avez des questions ou remarques, n’hésitez pas :slight_smile: J’espère que ce travail simplifiera la compréhension de chacun et que nous manipulerons plus facilement les différentes chaînes.

J’ai dû effectuer pas mal de modifications pour en arriver là, nous pourrons aussi en discuter dans la MR!182 dédiée.

6 Likes