Development #19659
support Django 1.11
0%
Description
Ticket créé à l'issue de l'atelier EOCamp à ce sujet.
Files
Associated revisions
tests: also run for django 1.11 (#19659)
History
Updated by Paul Marillonnet over 5 years ago
- File 0001-WIP-migration-django1.11.patch 0001-WIP-migration-django1.11.patch added
- Patch proposed changed from No to Yes
Un patch WIP produit à l'issue de l'atelier de l'EOCamp. Les éléments qui me laissent dubitatif pour l'instant :
- impossible de migrer en 1.11 sans retirer les structures conditionnelles de modification du dispatch des urls
if django.VERSION < (1, 8): from django.conf.urls import patterns urlpatterns = patterns('', *urlpatterns)
- impossible de d'exécuter le test test_views.test_invalid_msg_on_artifact_resolve
avec succès, dont l'erreur d'exécution n'a pas l'air d'être en rapport avec la version de Django utilisée. Le assert
sur la présence de 'ArtifactResolveResponse'
dans caplog.text
échoue puisque ce dernier vaut :
-> assert 'ArtifactResolveResponse is malformed' in caplog.text (Pdb) caplog.text u'views.py 274 INFO Got SAML Artifact Response\nviews.py 309 ERROR unexpected lasso error\nTraceback (most recent call last):\n File "/tmp/django-mellon/mellon/views.py", line 276, in continue_sso_artifact\n login.processResponseMsg(result.content)\n File "/tmp/tox-paul/django-mellon/coverage-dj19-sqlite/local/lib/python2.7/site-packages/lasso.py", line 3622, in processResponseMsg\n Error.raise_on_rc(rc)\n File "/tmp/tox-paul/django-mellon/coverage-dj19-sqlite/local/lib/python2.7/site-packages/lasso.py", line 62, in raise_on_rc\n raise exception\nServerProviderNotFoundError: <lasso.ServerProviderNotFoundError(-201): The identifier of a provider is unknown to #LassoServer. To register a provider in a #LassoServer object, you must use the methods lasso_server_add_provider() or lasso_server_add_provider_from_buffer().>\n'
-> On dirait que le fichier metadata.xml ne décrit plus un fournisseur valide pour melon. Je renomme ce dernier et ajoute un autre fichier contenant les métadonnées SAML2 de cresson, que je sais être valides. j'ajoute aussi la fixture associée d'artefact SAML valide. Pour contourner paresseusement le problème, le test d'invalidité de la résolution de l'artefact devient un test de validité. Je vais chercher à savoir pourquoi le test initial échoue.
- testé le fonctionnement de l'upgrade Django 1.11 qu'à travers les tests fournis avec les sources. J'écrirai un SP de test en Django 1.11 pour m'assurer déjà que des scénarios de SSO standards fonctionnent.
- pas encore essayé de générer le paquet Debian. C'est sur ma todolist.
Donc, pour l'instant, bien à l'état de WIP avec beaucoup à faire encore.
Updated by Benjamin Dauvergne over 5 years ago
Paul Marillonnet a écrit :
Un patch WIP produit à l'issue de l'atelier de l'EOCamp. Les éléments qui me laissent dubitatif pour l'instant :
- impossible de migrer en 1.11 sans retirer les structures conditionnelles de modification du dispatch des urls
[...]
Pourquoi ? Elles ne s'exécutent justement pas.
- impossible de d'exécuter le test
test_views.test_invalid_msg_on_artifact_resolve
avec succès, dont l'erreur d'exécution n'a pas l'air d'être en rapport avec la version de Django utilisée. Leassert
sur la présence de'ArtifactResolveResponse'
danscaplog.text
échoue puisque ce dernier vaut :
[...]
Je ne reproduis pas cette erreur de mon coté.
-> On dirait que le fichier metadata.xml ne décrit plus un fournisseur valide pour melon. Je renomme ce dernier et ajoute un autre fichier contenant les métadonnées SAML2 de cresson, que je sais être valides. j'ajoute aussi la fixture associée d'artefact SAML valide. Pour contourner paresseusement le problème, le test d'invalidité de la résolution de l'artefact devient un test de validité. Je vais chercher à savoir pourquoi le test initial échoue.
Non plus.
- testé le fonctionnement de l'upgrade Django 1.11 qu'à travers les tests fournis avec les sources. J'écrirai un SP de test en Django 1.11 pour m'assurer déjà que des scénarios de SSO standards fonctionnent.
Il y a un SP de test dans les sources justement.
- pas encore essayé de générer le paquet Debian. C'est sur ma todolist.
Installe le paquet eobuilder sur ta machine et lis en le README, http://git.entrouvert.org/eobuilder.git/tree/README.rst
J'attache mon patch minimal qui ajoute le support 1.11 et passe les tests.
Updated by Benjamin Dauvergne over 5 years ago
Amélioration à la condition sur la version (l'abandon des patterns() commence en 1.8).
Updated by Paul Marillonnet over 5 years ago
C'est plus simple comme ça.
Comprends pas pourquoi le test invalid_msg_on_artifact_resolve
ne passe pas chez moi, je cherche.
Updated by Benjamin Dauvergne over 5 years ago
Peut-être que c'est en rapport avec ta version de lasso ? Je suis en 2.5.1.17.g81fa-1~eob80+1.
Updated by Frédéric Péters about 5 years ago
- File 0001-tests-remove-django-1.8-leftovers-19659.patch 0001-tests-remove-django-1.8-leftovers-19659.patch added
- File 0002-tests-also-run-for-django-1.11-19659.patch 0002-tests-also-run-for-django-1.11-19659.patch added
- Status changed from Nouveau to En cours
Je tourne en 1.11 de manière globale chez moi sans soucis dans django-mellon; reste côté tests le minima, dégager un patterns() inutile; puis côté tox activer 1.11, et voilà.
Updated by Benjamin Dauvergne about 5 years ago
Ack, le problème des tests vient entièrement de la version de Lasso.
Updated by Frédéric Péters about 5 years ago
- Status changed from En cours to Résolu (à déployer)
commit 6d8e1ca517f0011bd66cb50310ad933d57d1564d Author: Frédéric Péters <fpeters@entrouvert.com> Date: Tue Jan 9 15:26:33 2018 +0100 tests: also run for django 1.11 (#19659) commit 18eb3a8632597d5863e80977e59c2fb4d6d351f3 Author: Frédéric Péters <fpeters@entrouvert.com> Date: Tue Jan 9 15:29:03 2018 +0100 tests: remove django < 1.8 leftovers (#19659)
tests: remove django < 1.8 leftovers (#19659)