Oh, man
C’était Nginx !
TL;DR :
rm -rf /var/nginx/cache/*`
Correction instantanée !
Facultatif : Désactiver la mise en cache des ressources Nginx
Modifiez ce fichier :
/etc/nginx/conf.d/discourse.conf
Autour des lignes 243-246, commentez les directives de mise en cache :
# proxy_cache one;
# proxy_cache_key "$scheme,$host,$request_uri";
# proxy_cache_valid 200 301 302 7d;
# proxy_cache_bypass $bypass_cache;
Puis redémarrez Nginx :
sv restart nginx
Si vous modifiez les palettes de couleurs…
Modifier simplement les paramètres de couleur dans le thème ne régénérera pas embed_[digest].css. Pour forcer Discourse à générer de nouveaux fichiers de ressources, faites ceci :
rm tmp/stylesheet-cache/* # ou, pour embed uniquement, `rm tmp/stylesheet-cache/embed*`
Qu’en est-il de RAILS_ENV=development ?
Vous pourriez penser que définir RAILS_ENV: development désactiverait la mise en cache, mais :
- Le fichier
nginx.sample.confutilisé par Discourse a la mise en cache activée par défaut, quel que soit l’environnement. - Cette mise en cache n’est pas liée à
RAILS_ENV, elle n’aidera donc pas à la mise en cache des ressources intégrées.
Donc, à moins que vous n’ayez l’intention de reconfigurer entièrement la couche Nginx, il suffit de vider le cache manuellement ou de désactiver ces lignes, et le tour est joué. Une fois que vous êtes prêt pour la production, vous pouvez revenir en arrière.
Qu’en est-il de ./launcher rebuild standalone ?
Bien sûr, cela fonctionne. Mais si vous modifiez activement des thèmes, testez des intégrations et ajustez des couleurs… vous voudrez quelque chose de plus rapide que d’attendre quelques minutes à chaque fois.