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
etg1
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 jobsbuild_network_runtime
etg1_data
se déclenchent simultanément et seulement sur déclenchement detrigger_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 fichiergenesis.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).
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 :
Merge request reports
Activity
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
added 1 commit
- b018dcd4 - #239 (closed): fix: create_client_release must not depend on runtime milestone
added RN-silent label
added 1 commit
- 47729817 - #239 (closed): feat: release du runtime depuis master
added 1 commit
- 2d49b03c - #239 (closed): fix: remove workaround from !239 (merged)
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)
mentioned in issue #269 (closed)
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
Toggle commit list-
0fcb69f1 - 1 commit from branch
mentioned in issue #239 (closed)
added 1 commit
- 994f4a6a - #239 (closed): feat: release du runtime from `runtime/*` branches
added 1 commit
- 95edb5ed - #139 (closed): fix: re-enable Docker ARM build
mentioned in issue #139 (closed)
requested review from @HugoTrentesaux
26 26 .is_network_branch: &is_network_branch 27 27 if: $CI_PIPELINE_SOURCE != "merge_request_event" && $CI_COMMIT_BRANCH =~ /^(network\/).+/ 28 28 29 .is_master_branch: &is_runtime_branch 30 if: $CI_PIPELINE_SOURCE != "merge_request_event" && $CI_COMMIT_BRANCH =~ /^(runtime\/).+/ Celui-ci extrait du fichier
runtime/gdev/src/lib.rs
la version du RuntimeDonc les actions à réaliser sont :
- créer une branche nommée runtime/peu-importe
- modifier dans le fichier
lib.rs
la version du runtime - commiter sur cette branche les modifications
- pousser
- 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 branchesruntime/
. D'ailleurs, en théorie, ces branches ne sont jamais mergées surmaster
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 commandeinject-runtime-code
est obsolète depuis !182 (merged) qui a introduit la variable d'environnementWASM_FILE
qui réalise l'injection lors de la commandebuild-spec
. Dans la CI, c'est le jobbuild_specs
qui alimente cette variable suite au jobbuild_network_runtime
qui a produit le runtime viasrtool
.À 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 uncargo run print-spec
.Edited by Cédric MoreauTrè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 leWASM_FILE
qui fait largement plus sens. On peut donc retirerinject-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 :- modifié le fichier
node/specs/gdev_client-specs.yaml
à la main - 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 utilisantprint-spec
, il manque un moyen d'éditer les chainspecs pour mettre à jour la partie "client specs" si on change les bootnodes par exemple.- modifié le fichier
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 jobbuild_raw_specs
qui va justement faire unprint-spec
suivi d'unbuild-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 unprint-spec
suivi d'unbuild-spec --raw
.Eh bien je me rends compte que pas du tout
je viens de créer #278 (closed) pour gérer ce point.
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
Toggle commit list-
43c696c2 - 1 commit from branch
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 mergermaster
surnetwork/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.
Edited by pokaJe 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.
- s'entraîner à maintenir un réseau dans le temps
C'est intéressant. Il ne restera probablement que les devs et les testeurs actifs ne reposant pas sur la partie effondré.
Edited by pokaOui, 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.
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
Toggle commit list-
fc1fe8f8 - 1 commit from branch
enabled an automatic merge when the pipeline for 6c1885cd succeeds
mentioned in commit 0f671ac6
mentioned in issue #278 (closed)