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 (notammentsrtool
qu’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-1000
sur laquelle j’ai modifié l’URL de la snapshot Ğ1 pour utiliser le serveur de Hugo et modifiéresources/gtest.yaml
pour ajouter mon compte et mes session keys (nécessaires pour que je puisse forger les premiers blocs). - Lancé le job
build_image
du 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.