Sono responsabile di un’installazione di Discourse basata su Docker, in esecuzione su Ubuntu, che ho ereditato nell’ambito di un progetto open source. Per anni l’ho aggiornata tramite git pull && ./launcher rebuild app e successivamente tramite l’interfaccia di amministrazione in /admin/update. Tuttavia, dopo un’esperienza dolorosa durante un aggiornamento che ha causato interruzioni, dovuto a docker_manager a gennaio 2024 (vedi i commenti sul commit qui e il commit revertito qui), ho smesso di aggiornare in modo così disinvolto.
Sono passati 2,5 anni e devo riprendere il ritmo degli aggiornamenti, ma sono ancora un po’ nervoso a causa dell’ultimo aggiornamento che ha causato problemi. Vorrei aiuto per capire cosa devo sapere prima di tentare l’aggiornamento da v3.4.0 a v2026.7.2. Il nostro sito non utilizza plugin aggiuntivi e l’unica configurazione speciale di cui sono a conoscenza è che utilizziamo un URL di Discourse Connect per avere SSO con il nostro sito principale della community.
È così semplice?
cd /var/discourse
git pull
./launcher rebuild app
E poi aggiornare tramite l’interfaccia di amministrazione? Ci sono dei passaggi intermedi di cui devo essere a conoscenza quando passo da v3.4.0 a v2026.7.2?
Oppure … (visto che sei nervoso) … fai un backup (in ogni caso) e configura un server completamente nuovo, ripristina il backup e poi, una volta completato, punta il dominio al nuovo server.
C’è anche un piccolo rischio che i plugin o i componenti del tema su cui fai affidamento non siano stati mantenuti, soprattutto se sono scritti da terze parti meno attive.
La nervosismo è il motivo per cui i SA esperti di Discourse usano una configurazione a due container, in modo da poter eseguire il bootstrap degli aggiornamenti prima di impegnarli (anche se questo non aiuterà molto quando hai un grande aggiornamento di Postgres, ma accadono raramente).
Ho provato l’aggiornamento oggi e, ancora una volta, mi sono scontrato immediatamente con una modifica non retrocompatibile nel ramo principale di discourse_docker:
Questo commit fa fallire le build e rompe l’installazione/la configurazione, ma è stato comunque unito al ramo principale. Era esattamente ciò di cui ero preoccupato.
L’esecuzione di ./launcher bootstrap app restituisce:
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
Come è possibile che modifiche non retrocompatibili vengano unite al ramo principale, che viene fornito come parte delle istruzioni di installazione ufficiali? I fallimenti delle build vengono ignorati? Lo stesso errore che sto riscontrando è presente proprio nel log di fallimento:
Sono riuscito a fare il checkout di un commit precedente che mi ha permesso di continuare con i passaggi di migrazione, ma ora sono a quota 2 su 2 per aggiornamenti rotti da commit non testati uniti al ramo principale.
Ciao @corywright, mi dispiace per il problema - l’ESR attuale non contiene il job, la patch è in fase di invio qui.
Riporteremo tutto a posto al più presto e mi assicurerò che l’obiettivo ESR venga aggiunto come target per i test di fumo per prevenire future regressioni.
Grazie ancora per aver suggerito questa opzione anziché un aggiornamento in loco. Ha funzionato molto meglio e mi ha permesso di partire da una copia fresca di un nuovo sistema operativo.
