Produits Entr'ouvert » w.c.s.

Le jenkins.sh c'est juste pour ne pas avoir de script dans la config de jenkins, on peut déjà l'ajouter sans passer à tox.

De #15534 :

Tu penses vraiment qu'il y a un rapport avec tox [...]

Je pense vraiment important que l'environnement d'exécution des tests soit stable, qu'on n'ait pas aux mauvais moments à devoir corriger des problèmes de l'environnement plutôt que se préoccuper du logiciel. Très certainement un environnement stable peut être atteint avec tox, sa config permettrait même d'avoir à la fois un job "stable" tout en ayant sur le côté un job "aventureux", qui tirerait les dernières versions de n'importe quoi.

Dans un cas des 'erreurs pointés (je viens de regarder hobo, fargo était dans mon souvenir similaire), après des exécutions sans problème du pip de l'environnement même (et l'info "You are using pip version 7.1.2, however version 9.0.1 is available."), quand arrive une exécution dans l'environnement tox, bim, plantage. Que ça soit tox, une mise à jour d'autre chose, notre utilisation qui fait qu'on nettoie mal des trucs, il y a un truc à régler là-dedans avant d'y confier w.c.s.

Si on veut séparer jenkins.sh de l'adoption de tox, pas de problème pour moi pour avoir un ticket en plus.

• ne pas utiliser le flag -r de tox qui force la recréation des environnements (on avait le même problème avec jenkins seul avant quand on ne cocher pas la case "Clear" dans le virtualenv builder).
• avoir déplacé le toxworkdir dans /tmp, ce qui fait que même en supprimant le répertoire de travail (ce que j'ai fait sur fargo, qui n'avait justement pas de toxworkdir défini) ça ne corrigeait pas le problème

Donc je préconise simplement d'ajouter le flag -r à tous les appels à tox dans les jenkins.sh.

J'ai donc repris les choses ici.

Il reste peu d'erreurs mais les résultats dont instables, pas les mêmes tests en erreur entre deux builds, et c'est idem en local (essayer tox -- tests/test_formdef.py::test_file_field_migration plusieurs fois d'affilée, puis pleurer). Tout à fait mystérieux pour l'instant.

tests.test_formdef_import.test_field_validation
tests.test_workflow_import.test_wscall_action

Les erreurs mentionnées ici manquent de contenu, faire -vv comme suggéré ?

tests.test_saml_auth.test_saml_login_page_several_idp[pickle]
tests.test_saml_auth.test_saml_login_page_several_idp[sql]

(je ne comprends pas trop, c'est comme si le setup_idp(4) avait juste configuré un seul IdP, et du coup un seul IdP redirect SAML plutôt que page intermédiaire.

Frédéric Péters a écrit :

tests.test_formdef_import.test_field_validation
tests.test_workflow_import.test_wscall_action

Les erreurs mentionnées ici manquent de contenu, faire -vv comme suggéré ?

tests.test_saml_auth.test_saml_login_page_several_idp[pickle]
tests.test_saml_auth.test_saml_login_page_several_idp[sql]

(je ne comprends pas trop, c'est comme si le setup_idp(4) avait juste configuré un seul IdP, et du coup un seul IdP redirect SAML plutôt que page intermédiaire.

C'est le fonctionnement normal sur /login/ ça prend le premier IdP (au pif parce que le référentiel d'IdP est un dico), le test est juste non-déterministe car dépendant de hashseed dans tox, et donc un peu foireux.

C'est toujours #10477 il me semble, en attendant on peut fixer un hashseed si vous voulez (un qui passe).

PS:

# wcs/qommon/ident/idp.py
1058     def login(self):
1059         idps = get_cfg('idp', {})
1060 
1061         # there is only one visible IdP, perform login automatically on
1062         # this one.
1063         server = misc.get_lasso_server()
1064         for x in server.providerIds:
1065             key_provider_id = misc.get_provider_key(x)
1066             if not idps.get(key_provider_id, {}).get('hide', False):
1067                 saml = get_publisher().root_directory_class.saml
1068                 return saml.perform_login(x)