On ne s’était pas rendu compte que build_raw_spec télécharge le gtest.json depuis la page de release précédemment poussé pendant les builds du runtime.
On a édité les bootnodes qu’au moment des builds clients, alors qu’on aurait dû le faire dès le début, en prérequis des build runtime.
Pour info en spécifiant les bootnodes dans le compose je me connecte bien au réseau.
L’image docker pour ceux qui veulent se connecter dessus: duniter/duniter-v2s-gtest-1100:1000-0.12.0
On refera un poste officiel lorsqu’on aura publié le client avec les bon bootnodes.
Oui c’est très bien, et non ça n’a pas besoin d’être fait avec le build du runtime (ça n’a d’ailleurs aucun rapport).
Je ne comprends pas votre soucis : gtest.json c’est le fichier de genesis, tandis que les raw specs sont la fusion de ce fichier et des spécifications du client gtest_client-specs.yaml.
Dans ton script build_raw_spec tu télécharges le gtest.json depuis les assets de release gitlab précédemment uploadé au moment du build runtime, il se base sur ça pour écrire les bootnodes, peu importe ce qu’on définit en bootnode dans node/specs/gtest_client-specs.yaml.
Tu peux essayer, tout ce qu’on met dans le gtest_client-specs.yaml en terme de bootnode n’est jamais répercuté dans release/client
La question porte sur le fichier release/client/gtest-raw.json qui ne contenait pas le bon bootstrap node lors du lancement des commandes xtasks client-build-deb et client-docker-deploy.
Est-ce que le bootstrap node est embarqué à la compilation et depuis quel fichier ? release/client/gtest-raw.json ou node/specs/gtest_client_specs.yaml ?
Non, ce revert c’était un ajout que j’avais fait dans la commande docker directement, mais qui s’avère inutile car ça fait doublon avec ton ajout au Dockerfile justement.
La commande embed est bien prise en compte, sans quoi il ne trouve par le runtime gtest.
ok mais du coup ça va toujours chercher à merger les bootnodes aussi du gtest.json, qui est généré au début lors des builds runtime, donc si on ne veut pas se retrouver aussi avec les anciens bootnodes en plus des notes, il faut bien définir les bootnodes au tout début, avant les build runtime ?
Sur la branche network/gtest-1100, j’ai fait quelques évolution à tes scripts de release @cgeek :
Nouvelle commande cargo xtask release qui fait proxy de toutes les autres, de manière à avoir le help de manière intuitive pour tout le flow
ex:
poka@pokaBook duniter-v2s % cargo xtask release
Compiling xtask v0.1.0 (/Users/poka/dev/duniter-v2s/xtask)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 2.66s
Running `target/debug/xtask release`
Release management commands (client, network, runtime)
Usage: xtask release <COMMAND>
Commands:
client Client release commands
network Network release commands
runtime Runtime release commands
help Print this message or the help of the given subcommand(s)
Options:
-h, --help Print help
Comme indiqué dans la doc release, on a préféré repasser en CI la partie génération des releases de manière à simplifier le multi arch sur les bons runner.
Ce flow est simplifié et automatisé via la commande cargo xtask release client create, qui va en gros:
Check que la release gitlab existe bien avec le bon tag
Check les assets déjà publié sur cette release gitlab
Lancer la pipeline avec les bons jobs pour chaque release manquante pour chaque arch, sur les bon runner
Attendre que les jobs finissent
Mettre à jour la release gitlab avec les nouveau assets généré par chacun des jobs
Ah cette branche n’est pas censé être mergé ? Pourquoi j’ai fait plusieurs changes pour le reboot, spécifiques, je pensais donc la merger.
Je l’ai fait sur cette branche pour ne pas imposer ces changes dans ta MR et pouvoir en discuter.
On peut cherry puck sur une 3ème branche (ou cherry pick sur ta MR direct oui en fait).
Mais par contre pour moi il fallait quand même merger le branche network.
On merge master vers les branches network mais pas l’inverse, car en toute rigueur dans les branches network on ne fait que modifier les spécifications réseau (gdev.yml, gtest.yml, g1.yml) ou celles du client, ainsi que les n° de version du client et du runtime.
Ok, mais du coup sur master on se retrouve avec un état des yml réseau obsolète, donc se serait bien de les supprimer totalement de master pour éviter les confusions.
Aussi, on a pas mal galéré avec les différentes version de config json et yaml éparpillé à différents endroits, c’est encore un peu flou mais je pense qu’on devrait pouvoir clean le git mais aussi simplifier le nombre de copie de fichier de config network. A creuser.
Mais c’est vrai qu’à l’époque des artifacts étaient commités (g1-data.json, raw specs) et que ce n’est plus le cas maintenant.
Comme ça, à chaud, je ne vois plus de problème à merger sur master tant que ces artifacts ne sont plus commités. Et si par erreur cela arrive (ce fut le cas avec la 1ère version de la gtest), on peut à nouveau faire du merge cherry-pické (donc pas de git merge).
Oui, en l’occurence ce sont les json qui se retrouve copié à différents endroits pendant les builds.
resources/ (bases)
node/spec/ (autre bases)
racine du repo/ (artefacts pendant les builds?)
release/ (cache des xtask)
Sachant qu’on parle de plusieurs json qui se ressemblent parfois et on tous un rôle légèrement différents, il y a différents raw spec par exemple.
C’est encore flou mais j’ai l’intuition que ça pourrait être légèrement simplifié.
J’ai cherry pick les commit concerné sur ta branche du coup.
J’ai rebase ma branche network du coup histoire d’avoir un git propre, mais je n’aurais pas dû car les tag de network créés dédouble virtuellement la branche, et supprimer ces tags supprimes les releases gitlab associés, j’ai déjà fait l’erreur, d’où le fait que la release client se retrouve avant la release runtime…
)