Resolve "Create a release from master"

Closes #239 Closes #269 Closes #139

Ci-dessous la nouvelle documentation du fonctionnement du pipeline de release réseau, client et runtime.

Documentation

Release du Runtime

A tout moment depuis la branche master, il est possible de créer une branche préfixée par runtime/, par exemple runtime/1000.

Depuis cette branche, il devient possible de déclencher un job trigger_runtime_release. Celui-ci extrait du fichier runtime/gdev/src/lib.rs la version du Runtime et en déduit la version de la milestone pour cette release de la forme runtime-<version>, par exemple runtime-1000, puis déclenche un job build_gdev_runtime qui va produire le runtime avec srtool.

L'exécution réussie de ce dernier job déclenche alors create_runtime_release qui va produire une page de release avec la milestone runtime-<version> contenant le fichier WASM compressé et les détails du runtime dans les notes de release. De plus, le job crée un tag runtime-<version> sur la branche master.

➡ pour le présent ticket, les runtimes gtest et g1 ne sont pas encore produits. Cela sera géré par #268.

Releases Réseau et Client

A tout moment, il est possible de tirer depuis master une branche de la forme network/<nom_reseau>-<version_reseau>, par exemple network/gdev-900.

Pousser une telle branche déclenche un pipeline de cette forme :

A chaque commit, le même pipeline se présentera.

Seules deux actions sont possibles :

• trigger_client_release : permet de déclencher la release du Client
• trigger_network_release : permet de déclencher la release du Réseau

Le reste des jobs découle de l'action choisie.

N.B. : la capture d'écran ci-dessus est légèrement obsolète : le job build_runtime a été renommé build_network_runtime, de plus les jobs build_network_runtime et g1_data se déclenchent simultanément et seulement sur déclenchement de trigger_network_release contrairement à ce que laisse penser la capture.

trigger_network_release

⚠ cette étape dépend du fichier https://dl.cgeek.fr/public/backup-g1-duniter-1.8.7.tgz qui est généré manuellement. Avant de procéder à une nouvelle release réseau, il convient d'actualiser ce fichier sans quoi la production du genesis risque de planter du fait des contrôles réalisés à cette étape.

Cette action déclenche alors :

• le job g1_data qui consiste à générer le fichier genesis.json utilisé pour la génération des specs du réseau ;
• le job build_network_runtime qui génère le runtime via srtool.

L'exécution réussie de ces deux jobs déclenche le job build_specs qui construit le fichier de spec du réseau (gdev.json pour la ĞDev).

Enfin, l'exécution réussie de build_specs déclenche automatiquement l'exécution du job create_network_release qui crée la release du réseau <nom_reseau>-<version_reseau> (ex. gdev-900) contenant :

• le fichier de spec
• le fichier genesis.json
• le fichier de configuration de spec ( gdev.yml)
• le runtime initial présent dans le fichier de spec

Exemple :

trigger_client_release

Cette action peut être réalisée à chaque commit, et peut notamment être réalisée dans le même pipeline que la release du réseau (dans ce cas il faut simplement attendre que cette dernière soit pleinement terminée).

🚩 La version du client sera extraite du fichier node/Cargo.toml, champ [package].version. Il découle ensuite de cette version celle de la milestone (client-<version>).

Prérequis :

• une milestone de la forme "client-<version>" (ex. : "client-0.9.1") utilisée pour créer la page de release en incluant les tickets et MR afférentes
• avoir déjà réalisé la release réseau au moins une fois
• ne pas avoir déjà réalisé la release du Client pour cette milestone

Cette action déclenche le job build_raw_specs qui va télécharger les specs de la release de réseau préalablement produite et générer les raw specs en incluant le fichier de clientSpec ( gdev_client-specs.yml par exemple).

En cas de succès, alors deux jobs sont déclenchés en parallèle :

• create_client_release qui va produire la page de release "<reseau>-<version_du_runtime>-<version_du_client>" (ex. gdev-900-0.9.1)

• docker_deploy qui va produire les tags sur dockerhub :