Resolve "Dissociate release of Runtime and release of Client"

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 :

---

Closes #195 (closed)

changed milestone to %runtime-802

added C-binary C-runtime P2-asap RN-silent labels

assigned to @c-geek

added 4 commits

• 74b1eeba - feat(#195 (closed)): `print-spec` and `release-network` commands
• f910a270 - feat(#195 (closed)): ci: handle `network/` branch
• be2b19cc - fix(#195 (closed)): arm64
• 4791d41e - fix(#195 (closed)): rebase on master

Compare with previous version

changed the description

changed the description

added 3 commits

• f894436c - feat(#195 (closed)): no benchmarks on network branch
• fd9dbb06 - fix(#195 (closed)): runtime-release must include srtool output
• 9ae99d34 - feat(#195 (closed)): release-runtime takes name argument

Compare with previous version

added 1 commit

• 0b123ed4 - fix(#195 (closed)): client release assets

Compare with previous version

marked this merge request as ready

requested review from @HugoTrentesaux

changed the description

Améliorations possibles :

• vérifier dès le déclenchement de trigger_client_release s'il manque la milestone ou si la release existe déjà, ou s'il manque la release réseau (requise)
• vérifier dès le déclenchement de trigger_network_release si la release existe déjà

ok, mais a priori seules des personnes qui savent ce qu'elles font appuieront sur ces boutons, donc ce sont des améliorations de confort non nécessaires ici

J'ai mis à jour le schéma graphql dans la branche hugo/195-graphql-schema pour vérifier que rien n'est cassé. J'ai utilisé le paquet npm get-graphql-schema. Mais je ne comprends pas comment le premier schéma a été généré par elois. Normalement la partie de l'API GitLab qu'on utilise est assez stable, mais on n'est pas à l'abri d'un changement. À voir si on en a besoin ou pas.

Je me rends compte en relisant que DEBIAN_FRONTEND: noninteractive n'est plus nécessaire.

Ça me semble bien comme ça et les explications sont claires. J'ai ajouté un lien vers la MR dans la doc (branche hugo/195-doc). Je pourrai reprendre cette doc développeur à un moment, mais pour l'instant c'est satisfaisant.

Merci beaucoup pour ce travail que je n'aurais pas pu faire aussi proprement vu mon expérience en CI ! Je découvre par exemple, le << en yaml qui est très pratique .

Tu peux merger sur master quand tu veux avec ou sans les dernières modifs optionnelles.

La seule contrainte que je ne comprends pas est :

ne pas avoir déjà réalisé la release du Client pour la même version du runtime

On peut vouloir publier une nouvelle version du client sans changer le runtime. Donc dans ce cas il faut quand même incrémenter la version runtime et avoir une milestone de runtime ? Dans un scénario où le runtime ne change pas, mais qu'on fait des mises à jour régulières de substrate et des dépendances qui modifient le client, on devrait donc quand même incrémenter la version du runtime ?

---

Une fois fusionné, je pourrai tester la publication:

• d'un nouveau runtime 802 en mergeant master sur network/gdev-800 en incluant en plus un commit similaire à 32ae886a pour renommer le runtime en 802
• d'un nouveau client pour le réseau gdev-800 simplement en appuyant sur le bouton "trigger_client_release"

approved this merge request

Merci. Toutefois les images Docker semblent avoir un soucis, je vais regarder.

Je vais partir en vacances fin juillet. Donc je reprendrai probablement à la rentrée en septembre. Je te laisse voir pour les images, tu peux fusionner les différentes MR approuvées dans l'ordre qui t'arrange.

Je reviens de 2 semaines de pause, j'ai repris le sujet des images Docker mais c'est un peu l'enfer à comprendre avec le cross-build et podman bon ça avance.

Je note que je peux merger quand j'estime cela prêt.

Ok, donc si je comprends bien c'est toujours dans tes mains, tu n'attends rien de mon côté ?

Non j'attends car master ne builde plus, mais tu as vu mon commentaire ici semble-t-il : !274 (comment 44033)

Suite au rebase sur !274 (merged), le build Docker ne passe plus. J'investigue, j'ai quelques autres soucis avec mon IDE aussi.

@HugoTrentesaux j'ai réussi à produire une release complète, mais il m'a fallu désactiver la production de l'image Docker pour ARM. J'ai créé #253 pour tracer et corriger le problème plus tard : on peut se contenter de nœuds x86 dans un 1er temps.

Concernant ta remarque :

La seule contrainte que je ne comprends pas est :

ne pas avoir déjà réalisé la release du Client pour la même version du runtime

On peut vouloir publier une nouvelle version du client sans changer le runtime.

Oui tout à fait : je suppose que je voulais dire "pour la même version du réseau". Je crois que l'idée était simplement de dire que la release ne doit pas déjà exister sinon le build plante, mais c'est logique.

Je te laisse me confirmer le merge, sinon tu peux le faire directement.

Effectivement, un problème pour les bindings rockdb lié à la libc ?

  /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
  thread 'main' panicked at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/librocksdb-sys-0.11.0+8.1.1/build.rs:40:10:
  unable to generate rocksdb bindings: ClangDiagnostic("/usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found\n")

On ne devrait pas en avoir besoin si on utilise paritydb, je regarde dans substrate/polkadot-sdk :

Je ne vois plus le commit "disable rocksdb by default" de https://github.com/duniter/substrate/commits/duniter-substrate-v0.9.42/ par @librelois dans https://github.com/duniter/duniter-polkadot-sdk/commits/duniter-substrate-v1.14.0/. On dirait que c'est redevenu une dépendance obligatoire : https://github.com/duniter/duniter-polkadot-sdk/blob/duniter-substrate-v1.6.0/substrate/client/db/Cargo.toml#L25. @bgallois tu confirmes ?

Ok pour x86 pour l'instant, @librelois prévenait que ARM serait plus expérimental et a proposé le rpi4 en connaissance de cause.

---

Ok aussi pour la remarque. Je m'occupe de merger après !272 (merged) et !277 (merged). Je tenterai une release sans ARM et proposerai un upgrade sur la gdev. Pour la #253, il faudra ajouter une étape à la CI, c'est en effet mieux de se rendre compte du problème en amont plutôt que au moment où on veut releaser !

Je ne sais plus, j'ai peut-être buggé dans la dernière mise à jour et oublié de la cherry-pick. Je vais m'attaquer à la prochaine mise à jour quand !272 (merged) sera mergée et je regarderai ça.

"disable rocksdb by default" de retour dans la 1.16.0 https://github.com/duniter/duniter-polkadot-sdk/commits/duniter-substrate-v1.16.0.

mentioned in merge request !274 (merged)

added 1 commit

• 1f0ff6ce - fix(#195 (closed)): cross-compilation was broken

Compare with previous version

added 14 commits

• 1f0ff6ce...3f32c4a8 - 2 commits from branch master
• 3f32c4a8...48898300 - 2 earlier commits
• 09550c40 - fix(#195 (closed)): arm64
• 5507ed12 - fix(#195 (closed)): rebase on master
• f2783a7d - feat(#195 (closed)): no benchmarks on network branch
• 08b493ea - fix(#195 (closed)): runtime-release must include srtool output
• 1bfada9e - feat(#195 (closed)): release-runtime takes name argument
• 501e10ff - fix(#195 (closed)): client release assets
• 76e4b7d9 - fix(#195 (closed)): cross-compilation was broken
• 3108f3b2 - fix: rebase on master
• 7f32280d - fix: remove vit and Maaltir as they are no more G1 members
• f2d5609e - fix: disable arm build (again)

Compare with previous version

mentioned in issue #253

added 1 commit

• 6948fa28 - fix: disable arm build

Compare with previous version

added 13 commits

• 6948fa28...d18c3437 - 2 commits from branch master
• 7eae2e91 - 1 earlier commit
• 594f684f - feat(#195 (closed)): ci: handle `network/` branch
• d73d0e4d - fix(#195 (closed)): arm64
• 59437ce9 - fix(#195 (closed)): rebase on master
• f4c4b309 - feat(#195 (closed)): no benchmarks on network branch
• a972f3fd - fix(#195 (closed)): runtime-release must include srtool output
• 18b6bf0b - feat(#195 (closed)): release-runtime takes name argument
• 54b0a793 - fix(#195 (closed)): client release assets
• 60b9d019 - fix(#195 (closed)): cross-compilation was broken
• 9c40c819 - fix: rebase on master
• 44d95bef - fix: disable arm build

Compare with previous version

enabled an automatic merge when the pipeline for 44d95bef succeeds

merged

mentioned in commit e26f94af

Seules deux actions sont possibles

En fait je rajouterais bien une troisième option create_runtime_release uniquement pour les runtime upgrade, parce que c'est pas la peine de publier un nouveau genesis à chaque fois qu'on veut faire un simple runtime upgrade.

[edit] j'avais oublié qu'on en avait déjà parlé et que c'était déjà dans le ticket #239 (closed)

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).

Vu qu'on gère les raw specs côté pipeline maintenant, ça aurait peut-être du sens de retirer les occurrences de

&include_bytes!("../specs/gdev-raw.json")[..],

et retirer les specs du dossier /specs/, non ? J'avoue être un peu perdu entre l'approche initiale d'elois qui consiste à commiter les raw specs et la nouvelle approche qui me semble plus logique mais pas encore terminée.

Oui on peut les retirer. Personnellement je ne trouve plus du tout le temps de le faire, par contre.

Un peu perdu aussi par ce qui se passe sur https://hub.docker.com/r/duniter/duniter-v2s-gdev-800/tags :

On est sur le réseau "gdev-800" (donc avec le runtime 800 dans le genesis), réseau qui est actuellement sur le runtime gdev-802, mais le tag est "801" puisque la branche runtime-801 a été mergée dans la branche network/gdev-800.

On peut juste ignorer le tag, et se contenter de latest, mais c'est pas encore tout à fait ça

Le tag est celui indiqué par le champ spec_version: du fichier runtime/gdev/src/lib.rs, comme indiqué dans le fichier gitlab-ci.yml.

D'ailleurs j'y vois un commentaire (décalé de la ligne qu'il commente) qui pourrait expliquer pourquoi il y a eu un soucis avec la page de release :

# GitLab milestone : used for both GitLab and Docker releases. Milestone must match source code's runtime version to fetch the git changes for release notes.

mentioned in issue #139 (closed)

changed the description