Closes #239 (closed) Closes #269 (closed) Closes #139 (closed)

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 :