# Industrialiser le démarrage d'une nouvelle Ğx
**URL:** https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535
**Category:** Duniter-v2s
**Tags:** g1, gdev, runtime
**Created:** [2 September 2023 10:29 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535 "2023-09-02T10:29:10Z")
**Posts on this page:** 1
**Showing post:** 3
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [4 September 2023 07:22 UTC](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/3 "2023-09-04T07:22:28Z")
Ce serait en effet super d’automatiser ce processus avec une CI ! Je ne m’étais pas lancé dedans pour plusieurs raisons :
- à l’époque je travaillais avec @poka et on y arrivait mieux en bidouillant des scripts exécutés avec un cron
- j’avais et ai toujours du mal avec cet outillage ([Difficultés avec l'outillage](https://forum.duniter.org/t/difficultes-avec-loutillage/9945))
- je ne suis pas confiant sur la CI et les GitLab runners ([Contribution souhaitée : CI GitLab de Duniter v2s](https://forum.duniter.org/t/contribution-souhaitee-ci-gitlab-de-duniter-v2s/11397), [Duniter indexer CI](https://forum.duniter.org/t/duniter-indexer-ci-is-failing/11142)), en partie parce qu’on manque de personnes pour faire l’admin sys quand il y a un panne et que je ne sais pas faire moi même
Mais si quelqu’un se lance dedans alors je vais faire tout mon possible pour l’aider !
* * *
> [@cgeek](#):
>
> @HugoTrentesaux tu avais démarré une branche [Commits · hugo-gtest · tools / py-g1-migrator · GitLab](https://git.duniter.org/tools/py-g1-migrator/-/commits/hugo-gtest), est-ce que tu veux la merger avant ?
Oui, il y a dedans du travail de réorganisation, commentaire de code, correction de bugs à conserver. Il y a aussi des modifications spécifiques à la ĞTest comme l’adaptation au format du genesis ĞTest, notamment le nom des champs (“index, owner\_key, membership\_expire\_on, next\_cert\_issuable\_on, certs\_received”).
Ces modifications vont de pair avec la branche `hugo-gtest` sur duniter-v2s. J’ai développé les deux en parallèle pour vérifier les entrées côté duniter et produire une sortie complète et cohérente côté py-g1-migrator.
Voilà pourquoi ce n’est pas mergé pour l’instant.
Et d’ailleurs, il y a aussi des modifications côté indexeur pour qu’il soit compatible avec les deux formats de genesis. (cf `index-genesis-gdev.ts` et `index-genesis-gtest.ts` dans [src/services · master · nodes / duniter-indexer · GitLab](https://git.duniter.org/nodes/duniter-indexer/-/tree/master/src/services)).
Il faut qu’on discute de ces différences et si ça vaut le coup de le conserver, j’ai ajouté ce point à l’ordre du jour de la [Visio dev -- mercredi 20 septembre 2023 -- 21h](https://forum.duniter.org/t/prochaine-visio-dev/11525).
* * *
> [@cgeek](#):
>
> dans le stage “deploy” rajouter un job “ **deploy-runtime** ” qui se chargerait de lancer la commande `cargo xtask release-runtime ` ET de publier le fichier `gdev_runtime.compact.compressed.wasm` sur la page de release
Il y a un [todo ligne 116](https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/xtask/src/release_runtime.rs?ref_type=heads#L116) à ce propos. Si je comprends bien, l’idée de faire ça est qu’on puisse télécharger le runtime depuis gitlab pour le soumettre sur la chaîne ?
Pour le reste, tout me semble ok. Et à mon avis on ne devrait rien mettre concernant les monnaie sur la branche master, et avoir une branche dédiée par réseau (`gdev6`, `gdev7`, `gtest`, `g1`). Ça éviterait de trop se mélanger les pinceaux et on pourrait utiliser le nom de branche pour générer l’image docker, par exemple `duniter/duniter-v2s:gtest` serait le "latest` sur le réseau gtest en cours (cf discussion [Release new image with ĞDev5 chainspecs - #46 by Moul](https://forum.duniter.org/t/release-new-image-with-gdev5-chainspecs/10723/46)).
---
_[View the full topic](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535)._