Industrialiser le démarrage d'une nouvelle Ğx

[cgeek]

La branche a été mergée. Petite présentation du nouveau processus de livraison que nous utiliserons pour prochainement relancer la ĞDev (700).

Créer une release

Création de la branche 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.

Job pour créer le tag et la page de release

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.

Le contenu de la page de 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.

Assets

Ce sont les livrables par défaut de toute release, même si certains ne seront pas exploités.

Les Runtime

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 ĞDev
• gtest_runtime.compact.compressed.wasm : le Runtime ĞTest

Les Spec

Ces 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.

En entrée

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 ĞDev
• gtest.json: le fichier de configuration du Genesis pour la spec du réseau ĞTest
• gdev_clients-specs.json: le fichier de configuration du Client pour la spec du réseau ĞDev
• gtest_clients-specs.json: le fichier de configuration du Client pour la spec du réseau ĞTest
• g1-data.json : le fichier de migration des données de la Ğ1 intégrées à la spécification des réseaux ĞDev et ĞTest

En sortie

Les 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

Runtimes

Les détails des deux Runtimes (bientôt trois avec la Ğ1) produits, un pour chaque réseau :

Les changements et tickets impliqués dans cette release

Créer ou rebooter un réseau (une monnaie)

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.

Commiter les chain specs

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 :

• gdev-raw.json
• gtest-raw.json
• g1-raw.json

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.

Builder les images Docker

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 ĞDev
• gtest_docker_release_build : pour builder l’image Docker du Client ĞTest
• gdev_docker_release_deploy : pour publier l’image Docker du Client ĞDev
• gtest_docker_release_deploy : pour publier l’image Docker du Client ĞDev