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 dansresources/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 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.