Tests E2E qui ne sont pas correctement joués sur la CI

cgeek · 10 November 2023 12:13

~~Ce bug va nous assez cher, car la CI “passe” sur master alors qu’en réalité les tests E2E ne passent plus depuis 7 commits (dont de grosses MR comme la !172).~~

~~J’ai consigné l’anomalie #132 car ça va bloquer le merge de !182 et donc le lancement de la ĞDev.~~

~~@HugoTrentesaux : aurais-tu le temps, non pas de corriger le bug #132, mais au moins les tests E2E sur la branche master ?~~

edit : a priori le bug était sur ma machine, les tests E2E y passent de nouveau quand je me place sur les commits des MR intégrées.

HugoTrentesaux · 10 November 2023 12:17

L’erreur du job est “No such file or directory”, ce qui arrive en général quand le fichier n’a pas été build avant (pour exécuter les tests end2end, il faut un exécutable ./target/debug/duniter). Et personnellement j’exécute régulièrement les tests end2end en local, ils passaient tous, sauf ceux liés au changement de la valeur de existential deposit dans ta branche.
Je vais essayer sur master, ils devraient fonctionner.

[edit]

Je confirme, sur master :

> cargo test -p duniter-end2end-tests
Running unittests src/lib.rs (target/debug/deps/duniter_end2end_tests-30c1730e5f16f6a4)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Running tests/cucumber_tests.rs (target/debug/deps/cucumber_tests-19aeea261ff4cbc2)
maybe_genesis_conf_file=Some("cucumber-genesis/default.json")
maybe_genesis_conf_file=Some("cucumber-genesis/default.json")
maybe_genesis_conf_file=Some("cucumber-genesis/default.json")
maybe_genesis_conf_file=Some("cucumber-genesis/wot.json")
Feature: Balance transfer
  Scenario: Create a new account with enough funds
   ✔  When alice sends 5 ĞD to dave
   ✔  Then dave should have 5 ĞD
   ✔  When 1 block later
      Then dave should have 2 ĞD
   ✔  Then dave should have 2 ĞD
  Scenario: Create a new account without enough funds then retry with enough funds
   ✔  When alice sends 2 ĞD to eve
   ✔  Then eve should have 2 ĞD
   ✔  When 1 block later
   ✔  Then eve should have 0 ĞD
      When alice send 5 ĞD to eve
   ✔  When alice send 5 ĞD to eve
   ✔  Then eve should have 5 ĞD
      When 1 block later
   ✔  When 1 block later
      Then eve should have 2 ĞD
   ✔  Then eve should have 2 ĞD
  Scenario: Create a new account without any funds
   ✔  Then eve should have 0 ĞD
   ✔  When eve send 0 ĞD to alice
   ✔  Then alice should have 10 ĞD
   ✔  When alice send 5 ĞD to eve
   ✔  Then eve should have 5 ĞD
   ✔  When 1 block later
   ✔  Then eve should have 2 ĞD
Feature: Certification
  Scenario: Dave certifies Alice
   ✔  When 2 blocks later
   ✔  When dave certifies alice
   ✔  Then alice should be certified by dave
Feature: Identity creation
  Scenario: alice invites a new member to join the web of trust
   ✔  When alice sends 7 ĞD to dave
   ✔  When bob sends 750 cĞD to dave
   ✔  When charlie sends 6 ĞD to eve
      When 15 block later
   ✔  When 15 block later
   ✔  When alice creates identity for dave
   ✔  Then dave identity should be created
   ✔  Then dave should be certified by alice
   ✔  When dave confirms his identity with pseudo "dave"
   ✔  Then dave identity should be confirmed
   ✔  When 3 block later
   ✔  When bob certifies dave
   ✔  When charlie certifies dave
   ✔  Then dave should be certified by bob
   ✔  Then dave should be certified by charlie
   ✔  When dave requests distance evaluation
   ✔  Then dave should have distance result in 2 sessions
   ✔  When 30 blocks later
   ✔  Then dave should have distance result in 1 session
   ✔  When alice runs distance oracle
   ✔  When 30 blocks later
   ✔  Then dave should have distance ok
   ✔  When eve validates dave identity
   ✔  Then dave identity should be validated
Feature: Balance transfer
  Scenario: After 10 blocks, the monetary mass should be 60 ĞD
   ✔  Then Monetary mass should be 30.00 ĞD
   ✔  Then Current UD amount should be 10.00 ĞD
   ✔  When 15 blocks later
   ✔  Then Monetary mass should be 60.00 ĞD
   ✔  When 10 blocks later
   ✔  Then Monetary mass should be 90.00 ĞD
   ✔  Then Current UD amount should be 10.00 ĞD
Feature: Oneshot account
  Scenario: Simple oneshot consumption
   ✔  When alice sends 7 ĞD to oneshot dave
   ✔  Then alice should have 3 ĞD
   ✔  Then dave should have oneshot 7 ĞD
   ✔  When oneshot dave consumes into account bob
   ✔  Then dave should have oneshot 0 ĞD
   ✔  Then bob should have 1699 cĞD
   ✔  Then bob should have oneshot 0 ĞD
  Scenario: Double oneshot consumption
   ✔  When alice sends 7 ĞD to oneshot dave
   ✔  Then alice should have 3 ĞD
   ✔  Then dave should have oneshot 7 ĞD
   ✔  When oneshot dave consumes 4 ĞD into account bob and the rest into oneshot charlie
   ✔  Then dave should have oneshot 0 ĞD
   ✔  Then bob should have 14 ĞD
   ✔  Then bob should have oneshot 0 ĞD
   ✔  Then charlie should have 10 ĞD
   ✔  Then charlie should have oneshot 299 cĞD
Feature: Balance transfer all
  Scenario: If bob sends all his ĞDs to Dave
   ✔  When bob sends all his ĞDs to dave
   ✔  Then bob should have 2 ĞD
   ✔  Then dave should have 798 cĞD
[Summary]
6 features
9 scenarios (9 passed)
71 steps (71 passed)
   Doc-tests duniter-end2end-tests

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

[Summary]
6 features
9 scenarios (9 passed)
71 steps (71 passed)

Tous les tests end2end passent, il n’y a pas de problème en local. Peut-être sur la CI, mais ça doit être parce qu’elle ne conserve pas le binaire ./target/debug/duniter qu’elle a compilé avant.

HugoTrentesaux · 10 November 2023 12:33

Pas besoin de corriger les tests E2E sur master, ils passent bien (cf le message précédent pour le détail). Pour reproduire en local :

cargo build
cargo test -p duniter-end2end-tests

cgeek · 10 November 2023 12:37

Je confirme, ils se mettent à passer sur ma machine . Ceci dit j’ai mis à jour le fichier metadata.scale entre-temps, je ne sais pas s’il y a un lien mais depuis cette action je n’ai plus de soucis.

Je vais voir pour corriger la CI du coup.

Tant mieux, j’ai eu peur que l’on ai de gros soucis de tests.

HugoTrentesaux · 10 November 2023 12:39

Oui, il y a un lien. subxt utilise le fichier metadata.scale pour connaître les types du runtime. Les tests end2end ont donc besoin d’être compilés avec la bonne version des métadonnées.

cgeek · 10 November 2023 12:40

D’où l’importance que la CI assure la bonne exécution des tests, de façon à montrer que le problème est plus proche de la chaise et du clavier.

cgeek · 14 October 2023 14:14

Je n’ai pas encore terminé cette partie. Par contre, j’ai l’impression qu’il y a un bug sur la CI car les tests Cucumber échouent et pourtant le job termine en succès : test_debug (#114330) · Jobs · nodes / rust / Duniter v2S · GitLab

Pini · 15 October 2023 14:40

Comme je le comprends, même si les cas test échouent, la commande cargo cucumber -i <cas-test> réussit (code retour = 0). C’est ça le problème. Ça devrait retourner un code d’erreur.

cgeek · 19 October 2023 11:30

Effectivement, dans le cas où l’erreur se produit à la construction des scénarios (et non pas à l’étape du test) :

Feature: Balance transfer all
  Scenario: If bob sends all his ĞDs to Dave
   ✘  Scenario's Before hook failed ./cucumber-features/transfer_all.feature:4:3
      Captured output: failed to spawn node: Os { code: 2, kind: NotFound, message: "No such file or directory" }

Tandis que si un test échoue, cargo cucumber ne retournera pas 0 et la CI échouera.

J’en profite pour te demander : y a-t-il une raison spécifique à avoir découpé les tests dans le Dockerfile ?

cargo cucumber -i account_creation* && \
cargo cucumber -i certification* && \
cargo cucumber -i identity_creation* && \
cargo cucumber -i monetary_mass* && \
cargo cucumber -i oneshot_account* && \
cargo cucumber -i transfer_all* && \

Plutôt que de lancer cargo cucumber ? Ce dernier a l’avantage de n’oublier aucun fichier si jamais nous en rajoutons.

Pini · 19 October 2023 12:28

Ça veut dire qu’il ne trouve pas l’exécutable node ? ^^

Non. À l’époque j’ai bêtement recopié ces commandes depuis le snippet correspondant de la CI :

  script:
    - cargo test --workspace --exclude duniter-end2end-tests --exclude duniter-live-tests
    - cargo cucumber -i account_creation*
    - cargo cucumber -i certification*
    - cargo cucumber -i identity_creation*
    - cargo cucumber -i monetary_mass*
    - cargo cucumber -i oneshot_account*
    - cargo cucumber -i transfer_all*

cgeek · 12 November 2023 08:29

J’ai une MR!189 qui corrige le soucis de tests E2E qui ne sont pas joués.

@HugoTrentesaux et plus particulièrement @Pini je veux bien votre approbation.

Pini : tu verras, les tests ne sont plus joués par le Dockerfile mais directement par la CI. D’ailleurs, j’étais surpris de cette façon de tester et de builder, est-ce du fait de la volonté de builder l’image Docker pour de multiples environnements ?

Pini · 12 November 2023 17:59

Non. C’est jusque que j’ai l’habitude de faire comme ça. L’idée est de builder systématiquement via Docker / Podman. Ça éviter de builder une fois en natif, puis de re-builder pour la conteneurisation. Et il m’a paru naturel ensuite de gérer les tests de la même façon.

cgeek · 12 November 2023 19:03

OK. Pas sûr que l’on conserve cette façon de fonctionner alors, les builds Docker étant plus l’exception que la règle (ce sont des releases du Client, ce qui est assez rare – nouveau démarrage de monnaie ou bien évolution de Runtime qui impliquerait une évolution de client), notamment dans le cadre de #122.

HugoTrentesaux · 13 November 2023 09:49

Je ne suis pas compétent pour relire la CI, mais je peux tester : j’ai introduit une erreur pour voir si la CI échoue bien au moment des tests : Pipeline · nodes / rust / Duniter v2S · GitLab
Une fois que ça échoue, je peux valider

cgeek · 13 November 2023 11:24

C’est bon, le test échoue je merge directement.