# Schéma de release pour Duniter #195

**URL:** https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284
**Category:** Duniter-v2s
**Created:** [25 May 2024 17:32 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284 "2024-05-25T17:32:40Z")
**Posts on this page:** 15
**Page:** 1

<div class="post-metadata">

### Author: ![HugoTrentesaux](https://forum.duniter.org/user_avatar/forum.duniter.org/hugotrentesaux/32/6396_2.png) [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [25 May 2024 17:32 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/1 "2024-05-25T17:32:40Z")

</div>

Nous avons une discussion sur [#195](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/195) avec @cgeek, je pense qu’elle peut être intéressante pour ceux qui veulent avoir des repères sur les concepts de réseau, client, runtime, specs… Je vais essayer de poser quelques bases ici que j’aurais apprécié lire clairement dans la doc et qui ne m’étaient pas apparues clairement dans le post d’@elois [Vocabulaire de base pour comprendre Duniter-v2s (lecture fortement recommandée pour tous)](https://forum.duniter.org/t/vocabulaire-de-base-pour-comprendre-duniter-v2s-lecture-fortement-recommandee-pour-tous/9053).

### Client

> **version elois**
>
> > [@Vocabulaire de base pour comprendre Duniter-v2s (lecture fortement recommandée pour tous)](https://forum.duniter.org/t/vocabulaire-de-base-pour-comprendre-duniter-v2s-lecture-fortement-recommandee-pour-tous/9053/1):
> >
> > Le binaire livré et installé par les gestionnaires de nœuds. Le Client est aussi parfois nommé “Binary” ou “Node”.  
> > Le client désigne tout ce qui ne se trouve pas dans le Runtime.  
> > Le logiciel duniter-v2s contient à la fois un Client substrate ET des runtimes (un par monnaie).

Le client est à la fois la “machine virtuelle” qui exécute le runtime, et le logiciel qui assura la connexion avec l’extérieur (couche p2p, API RPC, oracle de distance, keystore…). Le client inclut un runtime “natif” (mais on ne l’utilise pas sauf exception), plusieurs specs (par exemple `duniter --chain=dev`, `duniter --chain=gdev` pour un client compilé avec la feature `gdev`), cf le super post [État des lieux des différentes chaînes](https://forum.duniter.org/t/etat-des-lieux-des-differentes-chaines/11562).

### Runtime

> **version elois**
>
> > [@Vocabulaire de base pour comprendre Duniter-v2s (lecture fortement recommandée pour tous)](https://forum.duniter.org/t/vocabulaire-de-base-pour-comprendre-duniter-v2s-lecture-fortement-recommandee-pour-tous/9053/1):
> >
> > Partie de code qui contient les “Pallet” et leurs “Call”, elle est compilée en webassembly et le code webassembly du runtime est inclus dans le storage onchain, ce qui permet de mettre à jour le code du runtime via… des règles onchain définies par le runtime.
> > 
> > Plus précisément c’est le call `system.set_code(code)` qui met à jour le Runtime, il doit être exécuté avec l’Origine `Root`.  
> > Cela permet de faire des mises à jour dites “forkless”, c’est dire que lorsqu’un bloc contient le call `set_code`, le prochain bloc va automatiquement utiliser le nouveau runtime, sans que les gestionnaires de nœud n’aient besoin de mettre à jour leur nœud.

C’est à la fois **un élément de l’état** (_state_) en tant que “donnée binaire” et à la fois **la fonction de transition d’état** (_state transition_) interprétée en webassembly et exécutée à chaque bloc par le client pour passer d’un état au suivant. Elle peut être modifiée par la méthode `system.setCode(runtime)`, elle-même faisant partie du runtime.

### Spec

> [@Vocabulaire de base pour comprendre Duniter-v2s (lecture fortement recommandée pour tous)](https://forum.duniter.org/t/vocabulaire-de-base-pour-comprendre-duniter-v2s-lecture-fortement-recommandee-pour-tous/9053/1):
>
> Les _chain specification_ sont un ensemble d’informations décrivant un réseau précis. Elles sont composées de :
> 
> - des spécifications du client (nom/id de la monnaie, bootnodes, code substitute…)
> - un état genesis (bloc zéro) incluant le runtime initial
> 
> Certaines spécifications du client peuvent être modifiées après le lancement du réseau (par ex les bootnodes), alors que le genesis est fixé une fois pour toutes (d’où l’utilisation du hash du genesis comme identifiant de blockchain).

> **version hugo**
>
> La définition d’elois est très bien 😛. Pour plus d’infos, cf le code (je cite en simplifiant) :
> 
> → [duniter-polkadot-sdk/substrate/client/chain-spec/src/chain\_spec.rs at c84530c57a6f9ab808a92f6b5d29338acf1c6e4f · duniter/duniter-polkadot-sdk · GitHub](https://github.com/duniter/duniter-polkadot-sdk/blob/c84530c57a6f9ab808a92f6b5d29338acf1c6e4f/substrate/client/chain-spec/src/chain_spec.rs#L464-L468)
> 
> ```rust
> pub struct ChainSpec {
> client_spec: ClientSpec,
> genesis: GenesisSource,
> }
> 
> ```
> 
> → [duniter-polkadot-sdk/substrate/client/chain-spec/src/chain\_spec.rs at c84530c57a6f9ab808a92f6b5d29338acf1c6e4f · duniter/duniter-polkadot-sdk · GitHub](https://github.com/duniter/duniter-polkadot-sdk/blob/c84530c57a6f9ab808a92f6b5d29338acf1c6e4f/substrate/client/chain-spec/src/chain_spec.rs#L291-L320)
> 
> ```rust
> struct ClientSpec {
> name: String,
> id: String,
> chain_type: ChainType,
> boot_nodes: Vec<MultiaddrWithPeerId>,
> protocol_id: Option<String>,
> fork_id: Option<String>,
> properties: Option<Properties>,
> code_substitutes: BTreeMap<String, Bytes>,
> }
> 
> ```
> 
> → [duniter-polkadot-sdk/substrate/client/chain-spec/src/chain\_spec.rs at c84530c57a6f9ab808a92f6b5d29338acf1c6e4f · duniter/duniter-polkadot-sdk · GitHub](https://github.com/duniter/duniter-polkadot-sdk/blob/c84530c57a6f9ab808a92f6b5d29338acf1c6e4f/substrate/client/chain-spec/src/chain_spec.rs#L51-L60)
> 
> ```rust
> enum GenesisSource {
> File(PathBuf),
> Binary(Cow<'static, [u8]>),
> Storage(Storage),
> GenesisBuilderApi(GenesisBuildAction, Vec<u8>),
> }
> 
> ```

### Réseau

C’est la notion que me manquait au début. C’est à la fois simple car intuitif, et complexe car plein de concepts entrent en jeu.

Un réseau blockchain, c’est un ensemble de machines connectés ensemble qui exécutent le même code (runtime) en même temps. Un réseau peut avoir plusieurs clients différents. Ces clients peuvent être légèrement différents (version différente, architecture différente) ou même radicalement différents (autre implémentation dans un autre langage).

Le runtime d’un réseau peut évoluer au cours du temps (blocs de numéro croissant) lors des runtime upgrades. Ça reste le même réseau, mais toutes les machines se sont mises d’accord _en même temps_ de changer leur fonction de transition d’état.

Une chose qui a pu vous perturber est qu’on a utilisé des noms contre-intuitifs pour les différents réseaux gdev. Par exemple `gdev-700` et `gdev-800` étaient des réseaux différents alors que `gdev-801` est juste un autre nom pour le réseau `gdev-800` qui a juste connu un runtime upgrade. On aurait pu (et on pourra à l’avenir) les appeler `gdev-a`, `gdev-b` etc pour les réseaux successifs et comme ça `gdev-802` désignerait uniquement un **runtime** , et pas un réseau. Le même runtime pourrait être exécuté sur plusieurs réseaux.

> **subtilité**
>
> En fait, tous les clients n’exécutent pas forcément exactement le même runtime. Certains peuvent se risquer à exécuter un runtime différent (par exemple runtime natif plutôt que webassembly) du moment que la transition d’état est **exactement** la même. Mais c’est très découragé parce que si on trouve un résultat différent des autres, ils peuvent nous bannir \>\<

* * *

Voilà, j’espère que ça peut vous aider à vous y retrouver. En tout cas, même nous on est un peu perdus quand il s’agit de choisir le modèle de release \>\< (cf [#195](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/195) pour plus de discussions).

---

<div class="post-metadata">

### Author: ![HugoTrentesaux](https://forum.duniter.org/user_avatar/forum.duniter.org/hugotrentesaux/32/6396_2.png) [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [25 May 2024 18:15 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/2 "2024-05-25T18:15:51Z")

</div>

Maintenant ces bases posées (moi aussi ça m’a fait du bien de tout remettre à plat, tout n’est pas limpide dans ma tête), je peux proposer un schéma de branches de release.

- une branche master qui contient toutes les contributions
  - pas de numérotation du runtime
  - pas de numérotation du client

- une branche par réseau (`gdev-a`, `gdev-b`, `gtest`, `g1`) qui contient uniquement ce qui est pertinent pour ce réseau mais pas ailleurs
  - les `g1-data.json` pour alimenter le genesis
  - les “raw chainspecs” intégrées au binaire pour alimenter la commande `duniter --chain=<network>`
  - les mises-à-jour successives des bootnodes dans les chainspecs au cours de l’évolution des nœuds publics
  - des commits de merge de `master` lorsque l’on veut publier un nouveau client pour ce réseau (donc informer les gens qui ont des nœuds sur ce réseau de la disponibilité d’une mise-à-jour)
  - des commits de numérotation de ce client intégrant le nom du réseau (ex `1.2.3-gtest`)

- des branches de release du runtime basées sur master
  - ces branches ne contiennent qu’un commit de numérotation du runtime et du client d’après ce runtime (ex `900` et `0.0.0-900`)
  - elles mènent à la publication de trois runtimes, prêts à être utilisés pour des runtime upgrade sur chaque réseau (la seule différence entre le runtime `gtest` et `g1` étant des constantes du runtime)
  - elles mènent à la publication d’une client non destiné à un réseau existant (pas de chainspecs) mais destiné uniquement à des réseaux locaux de dev pour des environnements de dev (`duniter --dev`) mais qui démarre en utilisant ce runtime (`gdev`, il ne devrait pas y avoir de raison d’utiliser un autre runtime pour du dev local)

Les avantages que je vois à ce schéma sont :

- on met le minimum de choses sur les branches de réseau et on peut abandonner la branche si on abandonne le réseau
- les numéros de version sont toujours clairs, on évite de se retrouver avec une version numérotée qui n’est pas ce à quoi on s’attend
- on identifie clairement les binaires (et images docker associées) destinées à un usage réseau de celles dédiées à un usage de dev

Mais je veux bien des retours et je pense que @cgeek aussi vu que ça concerne un peu tous les devs de clients, forgerons, et administrateurs de noeud.

---

<div class="post-metadata">

### Author: ![vit](https://forum.duniter.org/user_avatar/forum.duniter.org/vit/32/2775_2.png) [@vit](https://forum.duniter.org/u/vit)
#### Post date: [26 May 2024 07:23 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/3 "2024-05-26T07:23:47Z")

</div>

Cela me paraît très bien.

Le reseau local avec alice et bob n’est présent que sur la branche du runtime si je comprend bien. C’est un cas particulier ? Il n’est pas dans la branche des réseaux ?

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [27 May 2024 11:40 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/4 "2024-05-27T11:40:18Z")

</div>

Je continue la revue ici, du coup. Globalement c’est plus clair.

Une seule chose à redire : je ne vois pas trop l’intérêt d’avoir des branches `gdev-a`, `gdev-b`.

Pour moi on peut se contenter de `gdev`, `gtest` et `g1`. Il n’y a _a priori_ pas deux `gdev` qui tournent en parallèle, et on n’est pas à l’abri non plus de rebooter une `gtest` régulièrement.

Les branches peuvent être écrasées au besoin.

---

<div class="post-metadata">

### Author: ![HugoTrentesaux](https://forum.duniter.org/user_avatar/forum.duniter.org/hugotrentesaux/32/6396_2.png) [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [27 May 2024 16:32 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/5 "2024-05-27T16:32:19Z")

</div>

Tout à fait d’accord, on peut avoir une branche `gdev` qui est la `gdev` actuelle et des branches `archive/gdev-a` si jamais on veut garder des traces d’une `gdev` passée.

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [27 May 2024 18:57 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/6 "2024-05-27T18:57:49Z")

</div>

Ok, je commence demain dans ce cas.

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [31 May 2024 10:56 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/7 "2024-05-31T10:56:25Z")

</div>

> [@HugoTrentesaux](#):
>
> une branche par réseau (`gdev-a`, `gdev-b`, `gtest`, `g1`) qui contient uniquement ce qui est pertinent pour ce réseau mais pas ailleurs
> 
> - les `g1-data.json` pour alimenter le genesis
> - les “raw chainspecs” intégrées au binaire pour alimenter la commande `duniter --chain=<network>`

Est-ce qu’on veut vraiment _commiter_ ces fichiers liés au Genesis ? Au final, à partir du moment où ces fichiers sont disponibles dans les releases GitLab, est-ce que ça ne suffirait pas ?

Ainsi les commits sur les branches de réseau contiendraient uniquement des modifications liées :

- aux fichiers de paramétrage (`gdev.yaml` et `gdev_client-specs.yaml`)
- aux numérotations du Runtime et du Client
- commits de merge

Je peux ajouter une commande `xtask` pour télécharger les livrables d’une version (g1-data.json, specs et raw-specs) et les copier en local.

Je dis cela pour éviter que la CI n’ajoute des commits “techniques” contenant les fichiers de specs et n’alourdissent le dépôt pour rien, vu que les releases porteront déjà les fichiers. Ce sont plus des fichiers de données que véritablement du code source.

---

<div class="post-metadata">

### Author: ![HugoTrentesaux](https://forum.duniter.org/user_avatar/forum.duniter.org/hugotrentesaux/32/6396_2.png) [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [31 May 2024 11:04 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/8 "2024-05-31T11:04:48Z")

</div>

Tu as raison, pas besoin de commiter ça, c’est justement ce que je reprochais au dépôt polkadot-sdk qui est archi lourd.

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [3 June 2024 20:07 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/9 "2024-06-03T20:07:37Z")

</div>

Pour réaliser ce tour de passe-passe il va falloir une condition : indiquer la version du Runtime du Genesis dans le nom de la branche de réseau. Par exemple : `network/gdev-800`.

C’est nécessaire car, pour un réseau donné, si l’on veut relivrer le client sans modifier le Genesis (et c’est obligatoire), alors c’est que ce dernier doit être dispoinble quelque part : et s’il n’est pas dans le code source, alors un bon candidat pour GitLab CI serait d’aller le chercher dans une _release_.

Typiquement : cette release aurait le nom du réseau + la version du 1er runtime. C’est un bon identifiant. Ainsi pour mon exemple il existerait une release `gdev-800` contenant :

- le fichier g1-data.json
- le fichier de configuration du Genesis (gdev.yaml)
- le Genesis (fichier gdev.json)
- optionnellement : le Runtime initial

Puis, pour chaque release du Client, une release de la forme :

```
<reseau>-<version-du-runtime-courant>-<version-du-client>

```

Par exemple :

```
gdev-801-0.8.0

```

Ces release _du Client_ ne contiendraient que les raw-specs résultantes de la fusion du Genesis et de la nouvelle version des ClientSpec, ainsi que le Runtime courant. Soit deux fichiers. Le Genesis serait retrouvé à partir du nom de la branche.

Ainsi, pas besoin de commiter le Genesis. OK pour toi @HugoTrentesaux ?

---

<div class="post-metadata">

### Author: ![HugoTrentesaux](https://forum.duniter.org/user_avatar/forum.duniter.org/hugotrentesaux/32/6396_2.png) [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [4 June 2024 08:51 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/10 "2024-06-04T08:51:45Z")

</div>

Joli tour de passe-passe ! Ça a le mérite de tout rendre explicite dans le nom de branche et le nom de release. On pourrait donc ajouter un mini texte dans la release pour informer sur sa nature. Par exemple :

> This release `gdev-800` was created for the gdev network with the gdev-800 runtime in its genesis. The files of this release are used in `network/gdev-800` branch to be included in the genesis.

Et dans la branche du réseau

> This branch `network/gdev-800` is used to publish updates for the `gdev-800` network. It’s using in its embedded chainspecs the genesis produced by the `gdev-800` release combined with the new client specs.

Donc en résumé le nom de branche `network/gdev-800` signifie que

- cette branche est dédiée à un réseau donné (network)
- ce réseau donné est identifié par le runtime de son genesis
- ce runtime peut être trouvé dans le release `gdev-800`

Une autre manière aurait été de nommer la branche `gdev` et de fournir le nom du release racine utilisé par ce réseau en tant que variable d’environnement pour la CI (par exemple `GDEV=gdev-800`).

Mais s’il est facile d’extraire l’info du nom de branche, c’est encore plus transparent de faire comme ça, et on pourra également s’en servir pour les noms des images docker, ce qui permettra de savoir clairement quel réseau on rejoint.

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [14 June 2024 10:26 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/11 "2024-06-14T10:26:05Z")

</div>

> [@HugoTrentesaux](#):
>
> - une branche par réseau (`gdev-a`, `gdev-b`, `gtest`, `g1`) qui contient
> - des branches de release du runtime basées sur master

J’ai globalement terminé le travail pour la branche par réseau. Comme je n’avance pas très vite en ce moment, je propose qu’on découpe le travail en deux tickets.

Qu’en dis-tu ?

---

<div class="post-metadata">

### Author: ![HugoTrentesaux](https://forum.duniter.org/user_avatar/forum.duniter.org/hugotrentesaux/32/6396_2.png) [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [14 June 2024 10:43 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/12 "2024-06-14T10:43:32Z")

</div>

Pas de problème à découper. Je peux toujours forcer un release en l’état actuel pour mettre à jour le réseau gdev si nécessaire. Quel serait le découpage en tickets ? Tu veux dire gérer les assets par release plutôt que dans un commit ?

De toute façon pour l’instant on n’a qu’un seul réseau donc les paquets debian et yunohost vont viser ce réseau quoi qu’il arrive.

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [14 June 2024 11:03 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/13 "2024-06-14T11:03:00Z")

</div>

Je veux dire que tu exprimais deux features : pouvoir faire des releases depuis une branche de réseau, et faire des releases depuis master.

Pour l’instant je n’ai pas couvert la feature “release depuis master”. Par contre la release depuis une branche réseau fonctionne comme prévu.

---

<div class="post-metadata">

### Author: ![cgeek](https://forum.duniter.org/user_avatar/forum.duniter.org/cgeek/32/279_2.png) [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [17 June 2024 10:51 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/14 "2024-06-17T10:51:02Z")

</div>

Voilà : ticket [#239](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/239) pour les releases depuis master.

J’essaie de terminer le [#195](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/195) maintenant, peut-être d’ici la semaine prochaine (dernière de juin).

---

<div class="post-metadata">

### Author: ![HugoTrentesaux](https://forum.duniter.org/user_avatar/forum.duniter.org/hugotrentesaux/32/6396_2.png) [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [2 December 2024 13:26 UTC](https://forum.duniter.org/t/schema-de-release-pour-duniter-195/12284/15 "2024-12-02T13:26:28Z")

</div>

@moul si tu veux regarder :

- [Dissociate release of Runtime and release of Client (#195) · Issues · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/195)
- [Resolve "Dissociate release of Runtime and release of Client" (!273) · Merge requests · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/273)
- [Create a release from master (#239) · Issues · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/239)