DOCUMENTATION OBSOLETE, REMPLACEE PAR CELLE DE !297 (merged)
Présentation de la feature
Réalisation découpée en deux parties :
la présente MR pour la branche master afin de bénéficier du nouveau workflow pour la prochaine branche réseau de la ĞDev
une branche network/gdev-800 avec un code un peu différent à cause des divergences intervenues sur master depuis
la branche network/gdev-800 sera adaptée après acceptation de la présente MR : comme il existe des différences, c'est difficile de réaliser le développement en parallèle et de répercuter les commits d'une branche vers l'autre. Donc je préfère qu'on acte le principe sur master d'abord puis que je fasse un rattrapage de la gdev-800 ensuite.
Fonctionnement général
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.
trigger_network_release
Cette action déclenche le job g1_data qui consiste à générer le fichier genesis.json utilisé pour la génération des specs du réseau.
L'exécution réussie du job g1_data déclenche alors, conjointement au succès de build_runtime, 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).
Prérequis :
une milestone de la forme "runtime-<version>" (ex. : "runtime-900") 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 la même version du runtime
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.8.0)
docker_deploy qui va produire les tags sur dockerhub :
