Development #86546
Proposition : purge du collectstatic après chaque mise à jour
0%
Description
Nous avons assez régulièrement des problèmes de mise en page suite à des mises à jour. Dans ce genre de situation, nous testons de lancer un authentic2-manage collectstatic et éventuellement un restart du service, mais dans certains cas, cela ne suffit pas. Dans ce cas, la plupart du temps, une purge manuelle du collectstatic règle le problème :
rm -fr /var/lib/authentic2/collectstatic/* authentic2-manage collectstatic
Proposition : que penseriez-vous de faire une purge de ce genre dans le postinst du paquet Debian pour éviter tout problème de ce type à l'avenir ?
PS : nous avons eut ce problème dernièrement à propos de la sidebar de la partie d'admin qui prenait tout l'écran.
Historique
Mis à jour par Thomas Noël il y a 3 mois
Pour info (mais c'est sans doute déjà vu) un "collectstatic" est lancé dans le service en ExecStartPre, juste après le migrate, voir https://git.entrouvert.org/entrouvert/authentic/src/branch/main/debian/authentic2.service
Y a-t-il une erreur lors du lancement de la commande collectstatic manuellement ?
Si non, cela ressemble plus à un problème de cache de ces fichiers statiques (côté reverse-proxy ou côté navigateur).
Dans tous les cas je pense que nous n'irons pas vers un "rm" du répertoire, c'est assez brutal et ça n'est normalement pas nécessaire (nous tournons beaucoup de logiciels Django en prod avec un simple collectstatic sans difficulté).
Mis à jour par Benjamin Dauvergne il y a 3 mois
Il y a pu y avoir des soucis, je ne sais plus pourquoi, lors du passage 2.2 -> 3.2 de Django au niveau de l'admin qui avait beaucoup bougée, mais l'admin est dépréciée de toute façon, on doit pouvoir tout faire dans le /manage/. Avez-vous souvenir d'avoir fait cette opération plus d'une fois pour une instance ?
Mis à jour par Benjamin Renard il y a 3 mois
Thomas Noël a écrit :
Pour info (mais c'est sans doute déjà vu) un "collectstatic" est lancé dans le service en ExecStartPre, juste après le migrate, voir https://git.entrouvert.org/entrouvert/authentic/src/branch/main/debian/authentic2.service
Y a-t-il une erreur lors du lancement de la commande collectstatic manuellement ?
Aucune erreur lors de collectstatic manuellement et effectivement, je suis au courant du collecstatic & migrate lors du démarrage du service.
Si non, cela ressemble plus à un problème de cache de ces fichiers statiques (côté reverse-proxy ou côté navigateur).
Non, là c'est clairement pas un problème de cache côté navigateur ou reverse proxy. C'est la première chose que j'ai vérifié.
Dans tous les cas je pense que nous n'irons pas vers un "rm" du répertoire, c'est assez brutal et ça n'est normalement pas nécessaire (nous tournons beaucoup de logiciels Django en prod avec un simple collectstatic sans difficulté).
J'en conviens.
Benjamin Dauvergne a écrit :
Il y a pu y avoir des soucis, je ne sais plus pourquoi, lors du passage 2.2 -> 3.2 de Django au niveau de l'admin qui avait beaucoup bougée, mais l'admin est dépréciée de toute façon, on doit pouvoir tout faire dans le /manage/. Avez-vous souvenir d'avoir fait cette opération plus d'une fois pour une instance ?
Je viens de vérifier sur les derniers cas dont je me souvenais et effectivement, c'était lors d'un upgrade incluant un passage de Django 2.2 à 3.2. J'ai souvenir d'avoir eut également à le faire par le passé lors de mise à jour majeur Debian et dans cette situation, ça bloquait carrément le démarrage du service car ça faisait planter le collectstatic (reproductible avec un lancement manuel). J'ai par contre pas souvenir d'un cas précis me permettant d'aller voir dans les logs si cela incluait un passage à Django 3.2.