Préparation programme Sprint 25sem41 - cournonsec (Hackaton Ğtest)

cgeek · 7 October 2025 10:39

Oui c’est ça.

poka · 7 October 2025 10:39

D’accord.

cgeek · 8 October 2025 20:38

Bon j’ai normalement tout sorti de la CI (gitlab-ci.yml ne fait plus que 128 lignes contre 479 avant ma branche), on a désormais l’équivalent en commandes xtask.

J’ai pu tester le workflow de reboot réseau commande après commande, ce qui a abouti a une release de test ici : gdev-1000-test · nodes / rust / Duniter v2S · GitLab

Mais je n’ai pas encore pu tester la release du client (via Docker déjà, puis DEB et RPM), et ensuite j’aimerais bien faire des commandes “haut niveau” afin de pouvoir faire :

Release réseau (à faire une fois au reboot d’un réseau genre gtest-1100)
Release client (à faire une 1ère fois au reboot réseau, puis à chaque màj du client)
Release runtime (utile pour les mises à jour du runtime ultérieures)

Je finirai de tester demain. Peut-être aura-t-on quelque chose d’exploitable demain midi, sinon demain soir. Je ne sais pas à quel point ça commence à gratter de votre côté.

poka · 8 October 2025 21:06

On peut attendre Vendredi, on s’occupe sur d’autres sujets.
On relis tes commits en attendant.

On trouve étonnant que tu internalises dans Duniter le packaging deb/rmp et autre dans Duniter au lieu de le laisser en CI.

Il faudra juste que tu nous décrive précisément le process du coup, étape par étape, qu’on profitera pour transformer en doc du coup

cgeek · 9 October 2025 11:53

Ce sera prêt ce soir.

cgeek · 9 October 2025 21:10

Hop, voici la doc : https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/329-allow-network-reboot-without-using-ci/docs/dev/release.md

Il est déjà tard donc je n’ai pas pu tout tester de bout en bout, je me suis arrêté à cargo xtask client-docker-deploy qui prend une plombe à exécuter et que j’ai donc coupé, mais que j’ai déjà testé indépendamment néanmoins.

Je vous laisse me faire des retours, si vous souhaitez tester par vous-mêmes sur une “fausse” release. Pour cela il faut simplement :

créer une “fausse” branche de réseau et remplacer dans les exemples network/gdev-1000 par le nom de votre branche de test comme 329-allow-network-reboot-without-using-ci
remplacer le nom de réseau gdev-1000 par une version suffixée comme gdev-1000-test

C’est comme ça que j’ai procédé pour tester. A titre d’exemple une commande que j’ai lancé il y a quelques minutes :

cargo xtask network-create-release gdev-1000-test 329-allow-network-reboot-without-using-ci

Comme cette commande crée une release dans GitLab, je l’ai supprimée depuis.

Voilà j’espère avoir fait avancé le schmilblick

C’est juste que ces livrables n’ont de sens que dans le cadre d’une livraison du Client, donc il n’y a pas de raison de faire différemment de la livraison de la version Docker : c’est-à-dire dans le cadre d’une release.

De sorte que le .gitlab-ci ne contient quasiment plus que de la CI.

Vraie release

On ne pourra en faire une qu’une fois la !344 afférente mergée sur master, mais aussi ~~!345 (restes de network/gtest-1000 non mergés) et~~ !343 (délai pour l’oracle de distance).

poka · 9 October 2025 22:45

Je ne sais pas à quoi correspond cette option embed que tu as rajouté, à quoi elle sert.

A préciser dans la doc que pour spécifier un network autre que gdev, passer l’argument --runtime au moment du network-build-runtime:

cargo xtask network-build-runtime --runtime gtest
Sinon gdev par défaut.

Même chose pour network-build-specs.

Cette commande produit une erreur:

cargo xtask network-build-specs --runtime gtest

→

...
   Compiling libp2p-dns v0.42.0
   Compiling x509-parser v0.17.0
error: failed to run custom build command for `litep2p v0.9.5`

Caused by:
  process didn't exit successfully: `/Users/poka/dev/duniter-v2s/target/release/build/litep2p-545c96ce311b6592/build-script-build` (exit status: 101)
  --- stderr

  thread 'main' panicked at /Users/poka/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/litep2p-0.9.5/build.rs:20:10:
  called `Result::unwrap()` on an `Err` value: Custom { kind: NotFound, error: "Could not find `protoc`. If `protoc` is installed, try setting the `PROTOC` environment variable to the path of the `protoc` binary. To install it on macOS, run `brew install protobuf`. It is also available at https://github.com/protocolbuffers/protobuf/releases  For more information: https://docs.rs/prost-build/#sourcing-protoc" }
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

Sur mac. Résolu avec brew install protobuf.
Mais je débouche alors sur une autre erreur:

Error: Input("failed to parse unknown field `protocolId`, expected one of `name`, `id`, `chainType`, `bootNodes`, `telemetryEndpoints`, `properties` at line 4 column 1")

Field rajouté par Elois il y a 3 mois dans gtest_client-specs.yaml, absent de gdev_client-specs.yaml

J’ai poussé le fix sur ta branche.

Ensuite pour la commande network-create-release, il cherche un gtest.yaml alors que c’est un gtest.json qui a été généré dans le dossier network:

...
2025-10-10 05:19:00 Building chain spec    
📋 Copie du fichier de configuration: resources/gtest.yaml -> release/network/llgtest.yaml
✅ Spécifications réseau générées avec succès!
📁 Fichiers disponibles dans le répertoire 'release/network/':
   - release/network/gtest.json
   - release/network/llgtest.yaml
poka@pokaBook duniter-v2s % cargo xtask network-create-release gtest-1100 network/gtest-1100
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.70s
     Running `target/debug/xtask network-create-release gtest-1100 network/gtest-1100`
rustc 1.91.0-nightly (7d82b83ed 2025-08-06)
cargo 1.91.0-nightly (840b83a10 2025-07-30)
🚀 Création de la release réseau pour: gtest-1100
📦 Runtime détecté: gtest
✅ Fichier trouvé: release/network/genesis.json
Error: Le fichier requis n'existe pas: release/network/gtest.yaml. Assurez-vous d'avoir exécuté les étapes de build précédentes.

poka@pokaBook duniter-v2s % ls release/network                          
block_hist.json                         genesis.json                            gtest_runtime.compact.wasm              tx_hist.json
cert_hist.json                          gtest.json                              llgtest.yaml
g1-dump.tgz                             gtest_runtime.compact.compressed.wasm   network_srtool_output.json

cgeek · 10 October 2025 06:11

Ça a été rajouté par @HugoTrentesaux fin 2023 pour la gtest, je cite le code :

// Return hardcoded live chainspecs, only with the embed feature enabled.
// Embed client spec and genesis to avoid embedding hexadecimal runtime
// and having hexadecimal runtime in the git history.
// This will only build on a branch that has a file named ./node/specs/gtest-raw.json.
#[cfg(all(feature = "gtest", feature = "embed"))]
"gtest" => Box::new(chain_spec::gtest::ChainSpec::from_json_bytes(
                &include_bytes!("../specs/gtest-raw.json")[..],
            )?),

Dans l’esprit le runtime devait être déduit du nom de la rease passé en paramètre. Donc gtest-1100par exemple devrait induire la gtest. Mais je n’ai pas encore testé.

edit : ah oui, j’ai corrigé. Il faut désormais passer le runtime en 1er argument. Exemple

cargo xtask network-build-runtime gdev

Sur un Mac Intel, le build peut passer (mais je n’ai pas de quoi tester). Sur un Mac ARM (puce Apple Silicon) le build du runtime ne passe chez moi avec un M1.

cgeek · 10 October 2025 06:14

Non le problème c’est le fichier llgtest.yml, il y a ce préfixe ll en trop je ne sais pas pourquoi.

edit : corrigé

poka · 10 October 2025 11:42

Chez moi ça passe Macbook pro M4.

C’est reparti ! (je repars de la génération des specs directement du coup).

La publication du network fonctionne !

poka · 10 October 2025 12:22

Est-ce que ça ne serait pas pertinent d’ajouter aux assets de cette release gitlab tous les fichier générés utiles pour l’indexer ? block_hist.json, cert_hist.json, tx_hist.json et genesis.json ?

La génération du package RMP s’arrête ici:

cargo xtask client-build-rpm gtest-1100
...
📦 Génération du package RPM...
stream did not contain valid UTF-8

La publication de la release client a bien fonctionné aussi (sans RPM): https://git.duniter.org/nodes/rust/duniter-v2s/-/releases/gtest-1000-0.11.0-test

Cependant on remarque que le numéro deversion client de la release est 1000, alors que j’ai bien définit 1100 dans toutes mes commandes et nom de branche.
Alors que pour la release runtime, le numéro était bien correct.

Par contre je ne vois pas de push sur docker hub
→
https://hub.docker.com/u/duniter

J’ai l’impression que deploy_docker.rs n’est pas executé, rien dans les logs à ce sujet.
Je comprends qu’il faut lancer manuellement la commande cargo xtask client-docker-deploy gtest-1100
A ajouter dans le doc peut être

L'ensemble des logs de la dernière commande

poka@pokaBook duniter-v2s % cargo xtask client-create-release gtest-1100 network/gtest-1100
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.62s
     Running `target/debug/xtask client-create-release gtest-1100 network/gtest-1100`
rustc 1.91.0-nightly (7d82b83ed 2025-08-06)
cargo 1.91.0-nightly (840b83a10 2025-07-30)
🚀 Création de la release client pour le réseau: gtest-1100
📦 Runtime: gtest
📦 Version client: 0.11.0-test
📦 Version runtime: 1000
🏷️ Milestone: client-0.11.0-test
📋 Nom de release: gtest-1000-0.11.0-test
✅ Fichier trouvé: release/client/gtest-raw.json
✅ Fichier trouvé: release/client/gtest_client-specs.yaml
📦 Packages trouvés:
   - duniter_0.11.0-test-1_arm64.deb (target/debian/duniter_0.11.0-test-1_arm64.deb)
🌐 Création de la release client GitLab...

# Client


# Changes



# Issues



📤 Upload des fichiers client vers GitLab...
📤 Upload de gtest_client-specs.yaml...
📎 Création du lien d'asset: gtest_client-specs.yaml -> https://git.duniter.org/-/project/520/uploads/200c5c0cafe70f03ee257e19a3c1d8fd/gtest_client-specs.yaml
📤 Upload de gtest-raw.json...
📎 Création du lien d'asset: gtest-raw.json -> https://git.duniter.org/-/project/520/uploads/dcd62414ef555fab5c38f490b563a373/gtest-raw.json
📤 Upload de duniter_0.11.0-test-1_arm64.deb...
📎 Création du lien d'asset: duniter_0.11.0-test-1_arm64.deb -> https://git.duniter.org/-/project/520/uploads/1bdb3e7eb5114964138899c450d03aa4/duniter_0.11.0-test-1_arm64.deb
✅ Release client créée avec succès!
📋 Résumé:
   - Réseau: gtest-1100
   - Runtime: gtest
   - Branche: network/gtest-1100
   - Release: gtest-1000-0.11.0-test
   - Milestone: client-0.11.0-test
   - Assets: 3 fichiers

On voit bien l’incohérence entre numéro de runtime du réseau et du client.

J’ai poussé des fix pour clippy.
Aussi poussé un fix RPM pour macos.

Pour le numéro de version incorrect je pense avoir compris, tu extrais le numéro depuis lib.rs du network concerné, mais celui-ci est set en dur à 1000.
Je pousse un fix pour extraire le bon numéro depuis notre runtime.
Mon fix version number fonctionne: https://git.duniter.org/nodes/rust/duniter-v2s/-/releases/gtest-1100-0.11.0-test

Pendant le process, il créer gtest.json à la racine du repo, et edit node/specs/gtest-raw.json.
J’imagine qu’il faut commiter ça sur notre branche de release ?
Le fichier gtest.json à la racine me semble curieux à cette place, c’est une création, bug de path?

(On pourra supprimer ces releases si on veut intégrer les 2 autres MR bien sûr, essai à blanc).

La publication de l’image Docker fonctionne: https://hub.docker.com/r/duniter/duniter-v2s-gtest-1100

Mais ça rajoute -test à la fin de l’image qu’il faudrait peut être retiré.

Malheureusement l’image ne fonctionne pas chez moi.

Mon docker compose

# docker-compose.yml template for running a Duniter smith node
# for more doc, see https://duniter.org/wiki/duniter-v2/
services:
  # duniter smith node
  duniter-v2s-smith:
    container_name: duniter-v2s-smith
    image: duniter/duniter-v2s-gtest-1100:1000-0.11.0-test
    ports:
      # RPC API of a smith node should not be exposed publicly!
      - 127.0.0.1:9944:9944
      # public p2p endpoint
      - 30333:30333
    environment:
      DUNITER_NODE_NAME: duniter_smith
      DUNITER_CHAIN_NAME: gtest
      DUNITER_VALIDATOR: true
      DUNITER_PRUNING_PROFILE: light
      DUNITER_PUBLIC_ADDR: /dns/tata.com/tcp/30333
      DUNITER_LISTEN_ADDR: /ip4/0.0.0.0/tcp/30333
    volumes:
      - duniter-smith-data:/var/lib/duniter
  # distance oracle
  distance-oracle:
    container_name: distance-oracle
    # choose the version of the image here
    image: duniter/duniter-v2s-gtest-1100:1000-0.11.0-test
    entrypoint: docker-distance-entrypoint
    environment:
      ORACLE_RPC_URL: ws://duniter-v2s-smith:9944
      ORACLE_RESULT_DIR: /var/lib/duniter/chains/gdev/distance/
      ORACLE_EXECUTION_INTERVAL: 1800
      ORACLE_LOG_LEVEL: info
    volumes:
      - duniter-smith-data:/var/lib/duniter

volumes:
  duniter-smith-data:

Logs:

poka@pokaBook compose % docker compose -f docker-compose.smith.yml up
[+] Running 4/4
 ✔ Network compose_default              Created                                                                                                                                                                                                         0.0s
 ✔ Volume "compose_duniter-smith-data"  Created                                                                                                                                                                                                         0.0s
 ✔ Container distance-oracle            Created                                                                                                                                                                                                         0.1s
 ✔ Container duniter-v2s-smith          Created                                                                                                                                                                                                         0.1s
Attaching to distance-oracle, duniter-v2s-smith
distance-oracle    |
distance-oracle    | thread 'main' panicked at /root/distance-oracle/src/api.rs:32:10:
duniter-v2s-smith  | Generating node key file '/var/lib/duniter/node.key'...
distance-oracle    | Cannot create RPC client: Rpc(ClientError(Client(Transport(Io(Os { code: 111, kind: ConnectionRefused, message: "Connection refused" })))))
distance-oracle    | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
distance-oracle    | Waiting 1800 seconds before next execution...
duniter-v2s-smith  | Error: Input("Error opening spec file `gtest`: No such file or directory (os error 2)")
duniter-v2s-smith  | Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })
duniter-v2s-smith  | Node peer ID is ''.
duniter-v2s-smith  | Starting duniter with parameters: --name duniter_smith --node-key-file /var/lib/duniter/node.key --public-addr /dns/tata.com/tcp/30333 --listen-addr /ip4/0.0.0.0/tcp/30333 --rpc-cors all --rpc-methods Unsafe --validator --blocks-pruning 14400 --chain gtest -d /var/lib/duniter --unsafe-rpc-external
duniter-v2s-smith  | Error: Input("Error opening spec file `gtest`: No such file or directory (os error 2)")
duniter-v2s-smith exited with code 1

J’ai compris, le soucis est justement l’autre MR avec le tag embed manquant. J’ai rebase ta MR sur master du coup.

cgeek · 10 October 2025 16:40

en fait c’était mon Docker Desktop qui était buggué (vieille version), super !

Oui pourquoi pas !

C’est déjà le cas :

cargo xtask client-docker-deploy <network>-<runtime-initial-version>
...
cargo xtask client-docker-deploy gdev-1000

A mon avis, on ferait mieux de rajouter un contrôle et d’arrêter le processus s’il y a incohérence. Là tu fais une release avec la version 1100 alors que le runtime est en dur à 1000, c’est une source de bug. Et ajouter éventuellement une option --no-runtime-version-check si on veut outrepasser.

Je dirais non car c’est un artifact, pas du code source. Celui-ci, comme les autres artifacts, est de toutes façons poussé sur une release. Ça va alourdir le clonage Git pour rien.

Je ne vois pas ce suffixe.

Je vais ensuite faire des remarques directement sur la MR.

poka · 10 October 2025 16:42

Ici: https://hub.docker.com/layers/duniter/duniter-v2s-gtest-1100/1000-0.11.0-test/images/sha256-ef00db8689b46d095adccbcc8ea8d3c0f98f4205b7099fb51ca323785e8bd040

cgeek · 10 October 2025 16:43

Ok c’est un misscommit, j’ai poussé “-test” dans le node/Cargo.toml.

poka · 10 October 2025 17:21

Ok lui en l’occurence est déjà versionné, il faut le supprimer et ajouter au gitignore comme le gtest.json racine alors.

Là j’ai des soucis de builds docker, j’ai poussé un fix pour que ça fonctionne sur MacOS mais visiblement pas suffisant, je vais peut être revert mon changement de build pour réduire l’entropie.

cgeek · 10 October 2025 19:37

C’est quoi le problème ?

poka · 10 October 2025 19:38

Juste le build multi arch depuis macos arm.

Mais hormis ça je galère juste à importer mes sessions keys via rotate key avec duniter portal à cause d’un bug d’import de clé mais je suis dessus.

Il y a quelque chose que je ne comprends, c’est à quel moment insérer mes session keys pour pouvoir forger les premiers bloc.
Car là actuellement mon noeud reste au bloc 0, du coup je ne peux pas rotate de key ni faire quoi que ce soit sur ce noeud.

Ais-je oublié quelque chose ?

cgeek · 10 October 2025 20:20

Regarde le fichier launch-a-live-network.md. Il n’est peut-être plus tout à fait à jour mais tu devrais y trouver ce que tu cherches.

edit :

Oui idem ça ne fonctionne pas, par contre aucun soucis depuis Linux x64.

En fait je n’ai aucune remarque.

poka · 11 October 2025 03:25

C’est pas mal le fait que ça publie le message de release gitlab, puis que ça vienne mettre à jour les assets des différents builds au fur et à mesure dans le message de release.

Mais du coup je pense qu’on va faire en sorte de repasser en CI les builds clients, une fois les artefacts runtime push, de manière à scinder sur différents runner les builds arm/x64 (j’ai un runner macos arm déjà), ne serait-ce que pour les builds deb arm/x64 par exemple, et pour docker aussi ce sera beaucoup plus rapide.

En tout cas c’est super d’avoir sortie tout ça de la CI, comme ça ce n’est plus dépendant de la CI, on compose comme on veut, et on peut juste lancer tes commandes dans un job si on veut.

aya · 11 October 2025 13:48

Le réseau gtest-1100 est lancé avec le bootnode :/dns/gtest.axiom-team.fr/tcp/30333/p2p/12D3KooWRsoY1uWFh5manQ7qjYt6bNiLTfJr9fAgcLz3mxwJY79y et ce fichier de specs.

Le build des images client a bien fonctionné par contre je n’ai pas vérifié le fichier gtest-raw.json avant de lancer la compilation et le bootnode n’a pas été pris en compte malgré la modification du fichier node/specs/gtest_client-specs.yaml…

On est bon pour un nouveau build des images client…