Je suis responsable d’une installation de Discourse basée sur Docker, exécutée sur Ubuntu, que j’ai héritée dans le cadre d’un projet open source. Pendant des années, je la mettais à jour via git pull && ./launcher rebuild app, puis via l’interface d’administration située à /admin/update. Cependant, j’ai cessé de mettre à jour si légèrement après une expérience douloureuse lors d’une mise à jour majeure due à docker_manager en janvier 2024 (voir les commentaires sur le commit ici, et le commit annulé ici).
Cela fait maintenant 2,5 ans et j’ai besoin de reprendre le rythme des mises à jour, mais je suis encore un peu nerveux à cause de la dernière mise à jour qui a cassé. Ce que j’aimerais comprendre, c’est ce que je devrais savoir avant de tenter de passer de la v3.4.0 à la v2026.7.2. Notre site n’utilise aucun plugin supplémentaire, et la seule configuration particulière dont je sois conscient est que nous utilisons une URL Discourse Connect pour avoir la SSO avec notre site communautaire principal.
Est-ce aussi simple que ceci ?
cd /var/discourse
git pull
./launcher rebuild app
Et ensuite de mettre à jour via l’interface d’administration ? Y a-t-il des étapes intermédiaires dont je dois tenir compte en passant de la v3.4.0 à la v2026.7.2 ?
Ou bien… (si vous êtes nerveux) … prenez une sauvegarde (dans tous les cas) et configurez un tout nouveau serveur, restaurez la sauvegarde, puis redirigez le domaine vers le nouveau serveur une fois terminé.
Le gros point auquel vous serez confronté est la mise à niveau majeure de Postgres (vers 18). Si vous construisez un nouveau serveur, vous n’aurez pas à gérer ce processus de mise à niveau.
Il existe également un petit risque que les plugins ou les composants de thème sur lesquels vous comptez n’aient pas été maintenus, en particulier s’ils sont écrits par des tiers moins actifs.
C’est précisément la nervosité qui pousse les administrateurs système Discourse expérimentés à utiliser une configuration à deux conteneurs, afin de pouvoir tester les mises à jour avant de les valider (bien que cela ne soit pas aussi utile lors d’une grosse mise à niveau de Postgres, mais celles-ci sont rares).
J’ai tenté la migration aujourd’hui et je suis immédiatement tombé sur une modification cassante (breaking change) dans la branche principale de discourse_docker :
Cet engagement (commit) fait échouer les builds et casse l’installation/la configuration, mais il a été fusionné dans la branche principale malgré tout. C’est exactement ce qui m’inquiétait.
L’exécution de ./launcher bootstrap app donne :
rake aborted!
Don't know how to build task 'assets:precompile:pretty_text' (See the list of available tasks with `rake --tasks`)
Did you mean? assets:precompile
Comment est-il possible que des modifications cassantes comme celle-ci soient fusionnées dans la branche principale, qui est fournie dans le cadre des instructions d’installation officielles ? Les échecs de build sont-ils ignorés ? La même erreur que je vois se trouve directement dans le journal d’échec :
J’ai pu vérifier (checkout) un engagement précédent qui m’a permis de continuer les étapes de migration, mais je suis maintenant à 2 sur 2 pour les mises à niveau cassées par des engagements non testés fusionnés dans la branche principale.
Merci encore d’avoir suggéré cette option plutôt qu’une mise à niveau sur place. Cela a beaucoup mieux fonctionné et m’a permis de démarrer avec une copie fraîche d’un nouveau système d’exploitation.
