Construction conteneurs de l’indexeur Squid pour la ĞTest

J’aimerais pouvoir release les images de l’indexeur pour que plus d’entre nous puissent mettre en place un indexeur sur la ĞTest.

@HugoTrentesaux @poka concernant le dépôt de l’indexeur, la branche gtest est misérable. Du coup, je pensais partir de la branche gtest-custom, mais je découvre qu’elle inclue la MR !27. Est-ce que ces changements sont toujours nécessaires après ce qu’a apporté Éloïs avec la Propositon pour obtenir facilement le solde d'un compte sans indexeur ?

Du coup, j’ai apporté mes changements sur une branche séparée :slight_smile:

2 Likes

:see_no_evil_monkey:

Oui, j’avais changé quelques trucs dans le genesis au cours de la MR !27 pour aider à débugger et je voulais les garder. On peut merger cette branche même si elle contient toujours un bug de calcul de la balance totale et travailler à sa résolution plus tard.

C’est très bien comme ça. Je pourrai m’occuper de la résolution des conflits quand je mergerai.

Les deux branches gtest et gtest-custom contiennent exactement la même chose, simplement le custom dans 3 commits au lieu d’un, et basé sur une branche de dev balance en effet. J’ai supprimé le doublon.

2 Likes

Je regarde pour mettre en place mes noeuds GTest et je me pose la question; est-ce que l’on a des images disponibles (en ARM64) pour SQUID/Indexer ?

Si je regarde les images disponible liées au compte duniter je ne vois rien de récent concernant SQUID :-/

https://hub.docker.com/u/duniter

Edit:
Je viens de retrouver que c’était sur le compte de @HugoTrentesaux; mais par contre pas de version ARM64 :-/

https://hub.docker.com/u/h30x

Je regarde pour tenter de refaire un build ARM64; mais je ne sais pas quelle branche prendre…

Il y a:

  • origin/gtest-custom
    22a9883 (2025-07-11 00:14:36 +0200) -  (origin/gtest-custom)please keep my fix for macos [poka]
    b71a573 (2025-07-10 12:50:12 +0200) - HOTFIX problem with cert hist format [Hugo Trentesaux]
    f5934d8 (2025-07-10 11:51:46 +0200) - GTEST typegen [Hugo Trentesaux]
    8a43af4 (2025-07-10 11:51:29 +0200) - GTEST custom changes [Hugo Trentesaux]
    38a4c91 (2025-04-18 22:09:19 +0200) -  (origin/account-balance)fix bad select [Hugo Trentesaux]
    77ac925 (2025-04-18 22:00:13 +0200) - remove unused variable [Hugo Trentesaux]
    ...
    
  • origin/ci_gtest
    a6cf38b (2025-07-16 15:36:18 +0200) -  (origin/ci_gtest)Adapt artifacts downloads for ĞTest [Moul]
    3acca73 (2025-07-16 15:26:04 +0200) - Remove outdated readme section [Moul]
    75f4c7c (2025-01-09 13:23:41 +0100) -  (HEAD -> main, origin/main, origin/HEAD)Bump hasura:graphql-engine to v2.45.1 (nodes/duniter-squid!29) [Moul]
    e9b5749 (2025-01-06 18:21:10 +0100) - compose: Use images from GitLab Registry (#46) [Moul]
    ...
    
2 Likes

Je pensais aussi construire ma propre image, parce que ce point traine.
Il faut les changements des branches ci_gtest et gtest-custom (avec ou sans les commits relatifs au calcul du solde).

3 Likes

Ce serais top si on arrive à ajouter la génération des images ARM64 également (histoire de rester cohérent, vu que l’on propose déjà duniter en ARM64 :slight_smile:)

3 Likes

J’ai tenté d’enlever les commits liés au calcul du solde avec DU, mais j’ai des conflits git.
Lorsque je lance docker.io/h30x/duniter-squid-gtest:latest ou une image construite sur gtest-custom avec les inputs téléchargés via la branche ci_gtest, j’ai cette erreur de migration de la db lors du démarrage :

[…]
Migration "Data1734887331842" failed, error: relation "event" already exists
query: ROLLBACK
QueryFailedError: relation "event" already exists
[…]

Migration introduite dans ce commit add udIndex to udReevals (6f12efda) · Commits · nodes / duniter-squid · GitLab

Je ne connais pas les détails de ce code, mais je suppose que tu as bien vérifié de partir d’une DB vide ?

Si les scripts de migration plantent alors que la DB est vide (et sans table) au départ, ce n’est pas normal :slight_smile:

Bien vu, en effet, il m’a fallu renommer le volume étant donné que j’ai l’indexeur ĞDev en parallèle.

Avec mon image construite localement, j’ai cette

erreur
{"level":2,"time":1753607679722,"ns":"sqd:commands","msg":"MIGRATION:COPY-CUSTOM"}
{"level":2,"time":1753607679728,"ns":"sqd:commands","msg":"MIGRATION:APPLY"}
query: SELECT version()
query: SELECT * FROM current_schema()
query: SELECT * FROM "information_schema"."tables" WHERE "table_schema" = 'public' AND "table_name" = 'migrations'
query: SELECT * FROM "migrations" "migrations" ORDER BY "id" DESC
No migrations are pending
{"level":2,"time":1753607679975,"ns":"sqd:commands","msg":"PROCESS:PROD"}
{"level":2,"time":1753607680306,"ns":"sqd:processor","msg":"processing blocks from 0"}
{"level":2,"time":1753607680307,"ns":"sqd:processor","msg":"using chain RPC data source"}
{"level":2,"time":1753607680316,"ns":"sqd:processor","msg":"prometheus metrics are served at port 33501"}
{"level":2,"time":1753607680465,"ns":"sqd:processor:mapping","msg":"Using genesis files from ./input/gtest.json, ./input/genesis.json, ./input/block_hist.json, ./input/tx_hist.json, ./input/cert_hist.json"}
{"level":2,"time":1753607680547,"ns":"sqd:processor:mapping","msg":"Last v1 block is 844944"}
{"level":2,"time":1753607680547,"ns":"sqd:processor:mapping","msg":"Handling v1 block history"}
{"level":2,"time":1753607681520,"ns":"sqd:processor:mapping","msg":"-800000"}
{"level":2,"time":1753607682025,"ns":"sqd:processor:mapping","msg":"-700000"}
{"level":2,"time":1753607682541,"ns":"sqd:processor:mapping","msg":"-600000"}
{"level":2,"time":1753607683072,"ns":"sqd:processor:mapping","msg":"-500000"}
{"level":2,"time":1753607683597,"ns":"sqd:processor:mapping","msg":"-400000"}
{"level":2,"time":1753607684155,"ns":"sqd:processor:mapping","msg":"-300000"}
{"level":2,"time":1753607684707,"ns":"sqd:processor:mapping","msg":"-200000"}
{"level":2,"time":1753607685790,"ns":"sqd:processor:mapping","msg":"-100000"}
{"level":2,"time":1753607686359,"ns":"sqd:processor:mapping","msg":"Saving v1 block history"}
{"level":2,"time":1753607692485,"ns":"sqd:processor:mapping","msg":"Loading genesis file"}
{"level":5,"time":1753607692806,"ns":"sqd:processor","err":{"stack":"TypeError: Cannot read properties of undefined (reading 'patch')\n    at saveGenesis (/squid/lib/genesis/genesis.js:119:103)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at async /squid/lib/main.js:21:13\n    at async TypeormDatabaseWithCache.performUpdates (/squid/node_modules/.pnpm/@belopash+typeorm-store@1.5.0_@subsquid+typeorm-config@4.1.1_typeorm@0.3.22_ioredis@5.4_87cf308fe95ce6fc0b5d015062ce0128/node_modules/@belopash/typeorm-store/lib/database.js:45:13)\n    at async /squid/node_modules/.pnpm/@subsquid+typeorm-store@1.5.1_@subsquid+big-decimal@1.0.0_typeorm@0.3.22_ioredis@5.4.1_pg@8.14.1_reflect-metadata@0.2.2_/node_modules/@subsquid/typeorm-store/lib/database.js:84:13\n    at async EntityManager.transaction (/squid/node_modules/.pnpm/typeorm@0.3.22_ioredis@5.4.1_pg@8.14.1_reflect-metadata@0.2.2/node_modules/typeorm/entity-manager/EntityManager.js:73:28)\n    at async TypeormDatabaseWithCache.submit (/squid/node_modules/.pnpm/@subsquid+typeorm-store@1.5.1_@subsquid+big-decimal@1.0.0_typeorm@0.3.22_ioredis@5.4.1_pg@8.14.1_reflect-metadata@0.2.2_/node_modules/@subsquid/typeorm-store/lib/database.js:164:24)\n    at async Runner.withProgressMetrics (/squid/node_modules/.pnpm/@subsquid+util-internal-processor-tools@4.2.1/node_modules/@subsquid/util-internal-processor-tools/lib/runner.js:217:22)\n    at async Runner.handleFinalizedBlocks (/squid/node_modules/.pnpm/@subsquid+util-internal-processor-tools@4.2.1/node_modules/@subsquid/util-internal-processor-tools/lib/runner.js:142:9)\n    at async Runner.processFinalizedBlocks (/squid/node_modules/.pnpm/@subsquid+util-internal-processor-tools@4.2.1/node_modules/@subsquid/util-internal-processor-tools/lib/runner.js:126:25)"}}

Je ne l’ai pas avec l’image d’Hugo. Les deux images n’ont pas la même taille. L’ayant construite sur la branche gtest-custom, il doit manquer un commit ou bien les inputs sont différents !?

1 Like

Je suis preneur également d’une image Arm64, toute mon infra tourne exclusivement sur cette architecture.

2 Likes

Désolé, je fais tout à moitié, je n’arrive rien à finir en ce moment. Quelques pistes de compréhension au moins en attendant de trouver temps et motivation pour corriger ça.
(je bouge dans un autre sujet pour faciliter le suivi)

Non, désolé, j’ai lancé un indexeur sur la gtest en mode bidouille et ai publié une image construite localement sur h30x/ mais n’ai pas pu contribuer au boulot de CI pour pouvoir publier toutes les images automatiquement et sur duniter/.

Je suis parti sur cette branche parce que même si on ajoute une entrée qui donne un résultat invalide, ça ne change pas le reste de squid. C’est crade, mais je ne voulais ni fusionner un travail non terminé ni repartir d’une version plus ancienne à laquelle il manque quelques corrections qui ont été nécessaires pour cette branche, ni faire le travail de trier les commits.

Effectivement pour l’instant les scripts de migration ne gèrent que le départ sur une db vide, ce ne sont pas de vrais scripts de migrations qui permettent de faire des montées en version (et c’est peu probable qu’on les fasse un jour vu que généralement il faut ré-indexer depuis le bloc zéro).

C’est sûrement lié aux données genesis, et plus précisément au “blockNumber”, modifié dans ce commit :

et cette MR py-g1-migrator : rename "blockNumber" with more explicit name (!7) · Merge requests · tools / py-g1-migrator · GitLab

Je vais essayer de prioriser la publication automatique et propre de duniter-squid mais je n’arrive vraiment pas à m’y mettre en ce moment. Beaucoup par manque de temps et un peu par manque de motivation pour gratter sur mes soirées.

3 Likes