-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Réinitialise le cache à chaque test de l'api #2761
Conversation
Pratique qui a besoin d'être validé auprès de notre DTC (ping @SpaceFox). Par hasard, est-ce que tu pourrais rajouter un test qui fait une requête sur la page 1 puis sur la page 2 et vérifier qu'il charge bien la page 1 pour la première requête et la page 2 pour la seconde ? |
C'est pas plutôt SpaceFox que tu voulais ping ?
Ok, je fais ça dans la semaine |
Bien, si Travis passe sur ces nouveaux assertions, la cause du bug de cache sur l'API en prod sera sans doute de l'infrastructure. Merci @DevHugo pour le test. |
Je suis heureux, que le test plante au moins, c'est pas que en prod ! Je l'ai pas sur mon env de dev à moi mais c'est cool ! ^^ |
Il ont discuté du bug dans cette conversation IRC (Pour une fois que l'irc sert à quelque chose =) ) . Les logs sont ici, mais il faut y aller avec la fonction rechercher, le mots clés est 'Pagination' et l'auteur est gmorell: https://botbot.me/freenode/restframework/2015-05-23/?tz=Europe%2FLondon&page=1. TLDR: Bug upstream dans ce fichier. La solution pour résoudre le problème rapidement est donné par gmorell. Il a créé une classe DJRF3xPaginationKeyBit qui corrige la classe PaginationKeyBit. Dans notre code, on aurait, class PagingPrivateTopicListKeyConstructor(DefaultKeyConstructor):
pagination = DJRF3xPaginationKeyBit() Faut se taper toute les classes qui utilise de la Pagination, et en plus faudrait re-changer quand la solution arrivera dans l'upstream. Mais elle marche, j'ai testé. Deux solutions:
Mais bon, pour moi, on est un peu hors-sujet. Les tests ne passe pas à cause du cache pas réinitialisé et pas de cette erreur qui est une autre issue pour moi. |
|
Même si travis passe, NE SURTOUT PAS MERGE ! Le prochain commit applique la correction de gmorell. Edit: la correction marche plutôt bien. |
Du coup "quoi de neuf ici" ? |
|
Avant de squash, les deux commits, j'aimerais bien qu'on confirme qu'on sépare pas la résolution en deux PR distincte: une pr pour corriger les tests unitaires et une PR pour le problème de cache de la pagination. Après faut faire un choix entre ses deux solutions: On attend qu'il corrige ça upstream (pas de PR en cours sur le sujet). Ensuite comme GerardPaligot dit :
|
Inutile de dupliquer les tags "Bloquant". L'issue l'est déjà. |
N'etant pas vraiment connaisseur du code, perso je te fais assez confiance sur ca @GerardPaligot . Si tu penses que le code est clean alors moi ca me va. Ensuite pour la QA, je sais que c'est pas terrible ce que je vais proposer mais on a pas vraiment le choix, ce souci est bloquant et il faut avancer, donc voila ce que je propose...
Ca vous va ? EDIT : Je rappel que cette PR est celle qui potentiellement resout notre dernier souci bloquant pour une release qui amenera entre autres la nouvelle home page... |
Pour moi, c'est le meilleur compromis. Je voulais l'avis de notre DTC (@SpaceFox) mais je n'ai jamais pu l'avoir.
Pourquoi ne pas tirer la branche sur la bêta ? |
parce que la branche est synchro avec dev, tu coup ca va ramener plein de bordel et faudra que je fasse l'equivelent d'une mise en prod' pour faire les choses bien et ca m'ennuie un peu (car besoin de mettre a jour les requirements etc... bref, je le sens moyen :D alors que le cherry-pick me permettera de tester de maniere vraiment atomique juste ce commit) J'en profite pour ping @pierre-24 qui fait une tentative chez lui en ce moment meme :) |
Il faut être sur que le cache est configuré correctement sur la préprod, je squash les deux derniers commits dans quelques minutes. Je peux rebase sur une branche particulière, si tu veux. |
C'est pas necessaire non :)
Normalement oui car on est cense etre iso-prod |
Faut créé une issue pour permettre de penser à reverse le commit quand la modification apparaîtra dans le master de drf-extensions. |
|
Bon, vous allez un peux vite pour que je suive, mais QA ok pour moi. Juste, qu'est ce que "bug de pagination" veux dire ? |
Pour constater le bug sur la prod:
Ce qu'ils faut tester aussi, tu active le cache (Memcached), et tu passe les tests unitaires. |
Ok pour la pagination. Par contre, je me tape une erreur qui a téoriquement rien à voir:
|
J'ai corrigé des tests donc c'est possible que ça soit liés. Tu avais memcache d'activé ? tu as lancé les tests avec quels commandes ? tu as l'ordre dans lequels se sont effectué ? |
Bah c'est bizarre ce test ne rentre pas dans la liste des tests affecte par tes changements... |
Je confirme, j'ai la même erreur en local. Memcached d'activé, python manage.py test |
Je l'ai sur dev aussi, mais j'imagine que c'est normal ... Je devrais essayer en désactivant memcached ? |
En désactivant memcache, ça marche =(. |
Donc c'est lié :( |
J'ai pas le temps aujourd'hui, qui veut regarde. |
Pourquoi travis ne bug pas alors ? |
et en ramenant ca ? #2756 |
C'est peut-être ça mais ça explique pas pourquoi travis ne bug pas. Pas le temps de testé, si vous voulez vous pouvez refaire une PR en cherry pick mes deux commits pour aller plus vite car pas très dispo en ce moment.
|
Avec la PR de spacefox, les tests repassent. Good to go ! |
Avant de merger il faudra donc "juste" verifier que la PR de spacefox ne casse rien, puis on la merge, puis celle-ci, puis on release, puis on conquit le monde, puis on se repose. Ok ? |
Ça me semble être un bon bon programme ! 2015-06-17 12:56 GMT+02:00 Eskimon notifications@github.com:
|
J'ai repris ici : #2816 en rebasant pour intégrer les modifications apportées par spacefox. |
QA: Normalement travis suffit + relecture du code.
Si vous voulez tester dans votre environnement