Suite au Development talk du vendredi 4 juillet, il a été convenu que j’essaie de bootstrap une ĞTest dans le week-end pour tester le processus.
Pour ce faire, j’ai notamment eu quelques préparatifs à effectuer :
- Adapté la CI de duniter-v2s pour qu’elle soit agnostique du nom du runtime (certaines parties avaient « gdev » codé en dur).
- Modifié la version des specs des runtimes à 1000.
- Testé la publication d’un runtime en créant une branche
runtime/1000: j’ai eu quelques erreurs à gérer (notammentsrtoolqu’il a fallu mettre à jour pour supporter le format v4 duCargo.lock). La publication du runtime a bien fonctionné, mais je l’ai supprimée ensuite car c’était juste pour tester la CI. - Mergé les paramètres de la ĞTest (après avoir appliqué les changements demandés par Hugo).
- Créé une branche
network/gtest-1000sur laquelle j’ai modifié l’URL de la snapshot Ğ1 pour utiliser le serveur de Hugo et modifiéresources/gtest.yamlpour ajouter mon compte et mes session keys (nécessaires pour que je puisse forger les premiers blocs). - Lancé le job
build_imagedu dépôttools/py-g1-migrator: l’image a été construite avec succès. - Lancé le job manuel
trigger_network_releaseà partir du dernier commit de la branchenetwork/gtest-1000, en suivant la doc écrite par cgeek.
La CI a alors échoué au job g1_data : g1_data (#147725) · Jobs · nodes / rust / Duniter v2S · GitLab
Il semble que l’image py-g1-migrator:latest ne contienne pas curl. Est-ce que @HugoTrentesaux ou @Moul peuvent regarder ?
J’aurais pu essayer de modifier la CI pour utiliser wget à la place de curl, mais le week-end touche à sa fin ![]()
Si un contributeur de py-g1-migrator a le temps de regarder, il faudrait s’assurer que l’image contient tout ce qui est utilisé ici : .gitlab-ci.yml · network/gtest-1000 · nodes / rust / Duniter v2S · GitLab
Si je retrouve du temps prochainement pour avancer, je vous tiendrai au courant dans ce sujet.