Resolve "Create a release from master"

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 :

changed milestone to %runtime-1000

added C-cicd D-medium ET-days I-ToPrioritize P2-asap labels

assigned to @c-geek

added 2 commits

• 00555964 - #239 (closed): refact: rename `release_runtime` module to `gitlab`
• 8a3b6fe8 - #239 (closed): fix: create_client_release must not depend on runtime milestone

Compare with previous version

added 1 commit

• b018dcd4 - #239 (closed): fix: create_client_release must not depend on runtime milestone

Compare with previous version

added RN-silent label

added 1 commit

• feb4aaa2 - #239 (closed): fix: mauvaise branche

Compare with previous version

added 1 commit

• 47729817 - #239 (closed): feat: release du runtime depuis master

Compare with previous version

added 1 commit

• df7d5b3d - #239 (closed): fix: srtool variables

Compare with previous version

added 1 commit

• 2d49b03c - #239 (closed): fix: remove workaround from !239 (merged)

Compare with previous version

added 1 commit

• 23fec5f4 - #239 (closed): test: runtime 1000

Compare with previous version

added 3 commits

• 5906820a - #239 (closed): fix: create_client_release must not depend on runtime milestone
• a3f407ab - #239 (closed): feat: release du runtime from master
• 73000cdd - #269 (closed): fix: remove workaround from !239 (merged)

Compare with previous version

mentioned in issue #269 (closed)

added 1 commit

• 641195ce - #239 (closed): fix: clippy

Compare with previous version

mentioned in merge request !273 (merged)

added 6 commits

• 0fcb69f1 - 1 commit from branch master
• fcfb8866 - #239 (closed): refact: rename `release_runtime` module to `gitlab`
• 3b5ec02f - #239 (closed): fix: create_client_release must not depend on runtime milestone
• f70edd44 - #239 (closed): feat: release du runtime from master
• 24c0a2ff - #269 (closed): fix: remove workaround from !239 (merged)
• f35403e2 - #239 (closed): fix: clippy

Compare with previous version

added 1 commit

• 0e2dc591 - test release runtime

Compare with previous version

added 1 commit

• 58f75ae4 - test release runtime 2

Compare with previous version

changed the description

marked this merge request as ready

mentioned in issue #239 (closed)

marked this merge request as draft

added 1 commit

• 994f4a6a - #239 (closed): feat: release du runtime from `runtime/*` branches

Compare with previous version

marked this merge request as ready

changed the description

added 1 commit

• 95edb5ed - #139 (closed): fix: re-enable Docker ARM build

Compare with previous version

mentioned in issue #139 (closed)

changed the description

requested review from @HugoTrentesaux

Je ne lis pas bien le yaml, y a-t-il un intérêt à avoir un nom différent pour le bloc et l'ancre ?

Aucunement, c'est un oubli de ma part quand j'ai décidé de requérir une branche runtime/ pour créer une release des runtimes plutôt que de pouvoir le faire depuis master. Je corrige.

Celui-ci extrait du fichier runtime/gdev/src/lib.rs la version du Runtime

Donc les actions à réaliser sont :

1. créer une branche nommée runtime/peu-importe
2. modifier dans le fichier lib.rs la version du runtime
3. commiter sur cette branche les modifications
4. pousser
5. déclencher le job trigger_runtime_release

En pratique, on aura tendance à nommer de manière à s'y retrouver, par exemple runtime/gdev-1000 pour un runtime visant à être mis en ligne sur un réseau gdev.

On pourrait reset à 000 la version des runtimes sur la branche master pour éviter de s'emmêler les pinceaux. Je ne connais pas les bonnes pratiques de versionnage, où vaut-il mieux mettre les commits qui bumpent les numéro de version ?

---

Pour moi cette MR répond bien à #239 (closed) (avec #139 (closed) et #269 (closed) en prime). Mais en relisant la doc complète j'ai d'autres questions :

• suite à la release du network qui produit les raw chainspecs, il faut bien commiter à la main (comme dans ae6d39ee) ?
• y a-t-il une raison pour avoir mis les chainspecs sur master dans 918d5828 ?
• il me semble qu'il manque une étape dans build_raw_specs: l'injection du runtime construit par srtool. Les étapes telles que je les comprends :
  • cargo xtask print-spec récupère les infos genesis (gdev.json)
  • cargo run -- build-spec --chain=gdev.json --raw > $RELEASE_FILE_RAW_SPEC construit les chainspecs
  • [manquant] injection du runtime srtool plutôt que natif avec cargo xtask inject-runtime-code. Ce n'est pas grave, mais ça limite la possibilité de vérifier que le runtime du genesis n'a pas été trafiqué par la personne qui bootstrape le réseau.
  • cargo xtask create-asset-link publie les raw specs telles quelles

Et quelques notes :

• quand on fait la MAJ de substrate, il faut aussi mettre à jour la version de srtool partout (CI, doc)
• la frontière entre assets de CI et fichiers à commiter n'est pas nette
• la procédure devient de plus en plus claire, il faut que poursuive le travail de doc que j'avais prévu dans 313f6da1 pour expliquer le fonctionnement de la CI

On pourrait reset à 000 la version des runtimes sur la branche master pour éviter de s'emmêler les pinceaux. Je ne connais pas les bonnes pratiques de versionnage, où vaut-il mieux mettre les commits qui bumpent les numéro de version ?

Oui tout à fait, je préconise également qu'on mette à 0 sur master. Et ensuite la version est exclusivement mise à jour sur les branches runtime/. D'ailleurs, en théorie, ces branches ne sont jamais mergées sur master car ce sont juste des branches utiles à produire une release.

suite à la release du network qui produit les raw chainspecs, il faut bien commiter à la main (comme dans ae6d39ee) ?

Non car nous évoquions justement que les chainspecs étaient plutôt une donnée qu'un code, et que par conséquent il valait mieux se contenter d'avoir les fichiers dans les pages de release plutôt que de polluer l'historique Git. D'où la commande cargo xtask print-spec qui va les chercher.

[manquant] injection du runtime srtool plutôt que natif avec cargo xtask inject-runtime-code. Ce n'est pas grave, mais ça limite la possibilité de vérifier que le runtime du genesis n'a pas été trafiqué par la personne qui bootstrape le réseau.

Je ne comprends pas cette remarque je vais peut-être répondre à côté. En fait pour moi cette commande inject-runtime-code est obsolète depuis !182 (merged) qui a introduit la variable d'environnement WASM_FILE qui réalise l'injection lors de la commande build-spec. Dans la CI, c'est le job build_specs qui alimente cette variable suite au job build_network_runtime qui a produit le runtime via srtool.

À noter que cette injection n'est réalisée qu'une seule fois pour la vie d'un réseau, lors de la création de celui-ci via la création d'une branche de réseau.

D'ailleurs, pour développer localement depuis la branche master tout en étant branché sur le nouveau réseau (via --chain=gdev_dev ou --chain=gdev_live), il faut réaliser un cargo run print-spec.

Très bien pour le 0 sur master.

Très bien pour les chainspecs "données" plus que "code".

Effectivement, j'avais oublié le remplacement de l'étrange WASM_BINARY de susbtrate (dont je ne comprends pas bien la provenance) par le WASM_FILE qui fait largement plus sens. On peut donc retirer inject-runtime-code dont la logique m'échappe depuis le début

À noter que cette injection n'est réalisée qu'une seule fois pour la vie d'un réseau, lors de la création de celui-ci via la création d'une branche de réseau.

Quand j'ai ajouté (à la hate) des bootnodes dans 007e22eb sur la branche network/gdev-800, j'ai :

1. modifié le fichier node/specs/gdev_client-specs.yaml à la main
2. modifié la partie "client specs" du fichier node/specs/gdev-raw.json à la main pour y reproduire les mêmes modifications

Quelle étapes suivre pour mettre à jour les client specs dans l'image docker publiée ? On ne peut pas utiliser build-spec qui n'est pas reproductible si le timestamp est différent ou si le code du genesis a connu un bugfix entre temps. En utilisant print-spec, il manque un moyen d'éditer les chainspecs pour mettre à jour la partie "client specs" si on change les bootnodes par exemple.

Quelle étapes suivre pour mettre à jour les client specs dans l'image docker publiée ?

Depuis la branche réseau, tu mets à jour le fichier gdev_client-specs.yaml comme d'habitude. Puis une fois le commit poussé sur la CI, c'est la release du client qui fait ça toute seule via le job build_raw_specs qui va justement faire un print-spec suivi d'un build-spec --raw.

C'est ce même job build_raw_specs qui est un prérequis à la release du client côté GitLab + pour produire le client Docker.

Bref selon moi tout est là, c'est limpide c'est bon signe.

c'est la release du client qui fait ça toute seule via le job build_raw_specs qui va justement faire un print-spec suivi d'un build-spec --raw.

Eh bien je me rends compte que pas du tout je viens de créer #278 (closed) pour gérer ce point.

approved this merge request

added 9 commits

• 43c696c2 - 1 commit from branch master
• 82364050 - #239 (closed): refact: rename `release_runtime` module to `gitlab`
• 60b3f880 - #239 (closed): fix: create_client_release must not depend on runtime milestone
• e7c55eec - #239 (closed): feat: release du runtime from master
• 28befb32 - #269 (closed): fix: remove workaround from !239 (merged)
• d84c2dc1 - #239 (closed): fix: clippy
• 4b977114 - #239 (closed): feat: release du runtime from `runtime/*` branches
• 145a1082 - #139 (closed): fix: re-enable Docker ARM build
• 6a017fb3 - fix: review

Compare with previous version

Comptes-tu bootstraper à nouveau la ĞDev ? Suite à #272 (closed) et #273 (closed) notamment. Sinon, suite au merge de la présente MR sur master, il faudra aussi merger master sur network/gdev-800 pour pouvoir faire des mises à jour du client avec la nouvelle mouture de la CI.

Ne serait-il pas également temps de lancer une ĞTest ? Si vous visez toujours la migration en Mars, il serait temps de:

• lancer et exploiter une ǦTest
• Communiquer à ce sujet (la migration pour Mars)
• Merger et publier ma MR !669 Cesium pour permettre une transition smooth et contrôlé

En 3 mois c'est faisable, mais seulement si on enclenche tout ça maintenant. Si on ne se jette pas à l'eau à un moment ou un autre, on ira jamais.

Je vois plusieurs avantages à conserver la gdev actuelle, qui permet de :

• s'entraîner à maintenir un réseau dans le temps
  • en renouvelant les adhésions et la toile forgeron
  • en gérant des runtime upgrade côté indexeur
• accumuler un peu de recul sur l'utilisation de ressources d'une "longue" chaîne
  • consommation d'espace disque / #267
  • consommation de ressources en aval, notamment pour observer le temps que Duniter-Squid met à indexer l'intégralité de la blockchain
• ne pas perdre les données d'historique de la communauté relativement importante de testeurs (Ğecko et autre)

Plutôt que de rebooter une gdev, je serais plutôt de l'avis de lancer la ĞTest, avec la communication suffisante pour avoir dès le début beaucoup de testeurs.

+1 pour l'entraînement et l'accumulation de données.

Par contre pour la ĞTest ça me paraît encore un peu tôt.

Je note que dans 2 mois, la toile de confiance ĞDev sera presque totalement effondrée. Il reste environ 700 comptes membres.

C'est intéressant. Il ne restera probablement que les devs et les testeurs actifs ne reposant pas sur la partie effondré.

Oui, et ça ne pose pas tellement problème tant que l'évaluation de la règle de distance est ok. Quoi qu'il arrive, on risque d'avoir les mêmes problèmes que la Ğ1-Test. Vu la valeur de la Ğ1, c'est pas gênant de tester en prod donc l'intérêt pour la ǦTest risque d'être limité. J'espère qu'on arrivera quand même à la maintenir en fonctionnement pour avoir un bon environnement pour tester les runtime upgrade à venir.

Storing this documentation in this repository would allow to find it easier later, rather than looking at a MR’s description. Having it in English would allow future non-French speakers developers to contribute.

Having it in English would prevent future non-English speaking developers from contributing.

I see this documentation within the MR as a preliminary document to specify the behavior of the CI. Integrating this (in english) to the repo documentation is a second step that should indeed follow soon.

added 9 commits

• fc1fe8f8 - 1 commit from branch master
• 880f0fb3 - #239 (closed): refact: rename `release_runtime` module to `gitlab`
• e76c5236 - #239 (closed): fix: create_client_release must not depend on runtime milestone
• b1cc44a6 - #239 (closed): feat: release du runtime from master
• 3036456c - #269 (closed): fix: remove workaround from !239 (merged)
• 05efb9c4 - #239 (closed): fix: clippy
• e9b9bf21 - #239 (closed): feat: release du runtime from `runtime/*` branches
• 2c3abdea - #139 (closed): fix: re-enable Docker ARM build
• 6c1885cd - fix: review

Compare with previous version

enabled an automatic merge when the pipeline for 6c1885cd succeeds

merged

mentioned in commit 0f671ac6

mentioned in issue #278 (closed)