Questo aggiornamento non funziona per me e al momento tutti e 3 i miei forum Discourse sono offline.
La finestra della console nella schermata di aggiornamento non mostra nulla, ma il resto dell’interfaccia utente suggerisce che l’aggiornamento è ancora in corso (ma questo ha già richiesto molto più tempo di qualsiasi aggiornamento abbia mai fatto).
Qualcun altro sta riscontrando questo problema? Avete idee su come posso completare con successo l’aggiornamento?
@pearsonified poiché questo include un aggiornamento del componente Rails, questa è una di quelle release che necessita di un aggiornamento dalla riga di comando.
Ah, è questo il problema con l’errore ruby 3.0 e web-push-3.0.0?
L’interfaccia utente di aggiornamento dell’amministratore dovrebbe dirlo all’utente piuttosto che lasciargli fare clic su “aggiorna tutto” e ritrovarsi con un forum completamente rotto. Risparmierebbe a molti utenti delle palpitazioni cardiache.
Nessuna idea; personalmente non uso mai la GUI per gli aggiornamenti, li faccio sempre da riga di comando. Non ho visto errori simili. Ma d’altronde non li avrei visti.
La maggior parte delle volte, quando si vede un messaggio di errore generico, se lo scenario specifico fosse stato previsto a sufficienza per un messaggio di errore specifico, sarebbe stato evitato.
Suppongo sia un bene che il problema “aiuto il mio aggiornamento GUI è fallito” sia così raro che la maggior parte delle persone non si renda conto che la prima cosa da fare è semplicemente eseguire git pull; ./launcher rebuild app per la distribuzione predefinita. È quasi sempre la risposta qui.
Ma è la cosa generale da fare se l’aggiornamento della GUI fallisce.
Uso Discourse da molti anni ormai. Tipo 7? Comunque, non ho mai avuto un aggiornamento web fallire catastroficamente prima. È fallito ovviamente, ma il forum è sempre tornato in vita perché ha eseguito il rollback e avviato il vecchio container.
Non è un errore generico, la cosa del ruby è piuttosto chiara.
web-push-3.0.0 richiede la versione ruby >= 3.0, che è incompatibile con la
versione corrente, 2.7.6
Docker Manager: AGGIORNAMENTO FALLITO
Mi starei lamentando abbastanza forte di questo se pagassi per Discourse. Non perché c’è un grosso bug che ha distrutto il nostro forum, i bug succedono, ma perché non è stato risolto almeno negli ultimi 3 giorni. Così com’è, solo un po’ di eccitazione alla fine della giornata.
Dal punto di vista del gestore di Docker, quel codice, al momento in cui è stata scritta la versione già in esecuzione, non sapeva che in futuro si sarebbe verificato questo problema. Capisco che tu sia frustrato, ma ciò che stai chiedendo potrebbe non avere senso dal punto di vista tecnico.
Se avessi pagato per Discourse, sarebbero loro a gestire questo processo e tu non lo vedresti mai. 
Anche se tecnicamente impossibile da correggere, potreste inviare email agli utenti per avvertirli di aggiornare tramite CLI. Fate rumore al riguardo. Rompere i forum senza rollback è cattivo.
Pensavo che Discourse vendesse anche supporto per l’uso on-premise? In ogni caso, non posso lamentarmi troppo forte dato che non sono un cliente pagante, ma caspita, 3 giorni non è un granché.
Sono felice per te che sia la prima volta in sette anni che devi ricorrere a questo, ma:
Chiamerò questa una falsa rappresentazione. CDCK raccomanda effettivamente i backup prima degli aggiornamenti come best practice. Ho visto molte volte qui su meta la nota che se l’aggiornamento della GUI fallisce, si ricorre alla ricostruzione dalla riga di comando, come parte delle normali aspettative per l’amministrazione del proprio forum. Loro non hanno rotto i forum senza rollback, quindi la tua implicazione è falsa.
Non starò qui a discutere per ore. Penso solo che tu non sia completamente ragionevole qui.
Inoltre, aggiornare un server di produzione senza eseguire l’aggiornamento attraverso una qualche forma di ambiente di staging è solo chiedere guai.
Non deve essere una copia su larga scala, un VPS da 5$ sarà sufficiente per la maggior parte. Se vuoi evitare tempi di inattività e la necessità di ricorrere ai tuoi backup, è l’assicurazione più economica che puoi ottenere.
Ho appena testato questo su un’istanza DO di prova che non è stata aggiornata da secoli:
e come segnalato si è verificato un errore:
Fetching gem metadata from https://rubygems.org/.........
Fetching https://github.com/rails/sprockets
web-push-3.0.0 requires ruby version >= 3.0, which is incompatible with the
current version, 2.7.6
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:209:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:93:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:20:in `block in fork'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:18:in `fork'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:18:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands/runner/runner_command.rb:43:in `load'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/command/base.rb:87:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/command.rb:48:in `invoke'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands.rb:18:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
bin/rails:18:in `<main>'
Spinning up 3 Unicorn worker(s) that were stopped initially
e la pagina di aggiornamento ora mostra:
e il sito principale restituisce un errore 500. In /logs vedo questo errore:
NoMethodError (undefined method `navigation_menu' for #<Class:0x00007fdffcb1b2f8>)
lib/wizard/builder.rb:98:in `block in build'
lib/wizard.rb:25:in `append_step'
lib/wizard/builder.rb:61:in `build'
lib/wizard.rb:110:in `requires_completion?'
lib/wizard.rb:117:in `user_requires_completion?'
app/serializers/site_serializer.rb:171:in `include_wizard_required?'
...
@pearsonified @mcdanlj Potete incollare gli errori che stavate ricevendo?
Non so se possiamo fare qualcosa ora per evitare questo per gli utenti futuri, ma ci daremo un’occhiata.
Nel frattempo, i seguenti passaggi hanno aiutato?
Eseguirò gli aggiornamenti dalla riga di comando stamattina e vedrò come va. I forum sono giù da 18 ore 
Se mi stessi chiedendo sì, la ricostruzione della CLI ha funzionato bene. Sono un SA decente e ho trovato la soluzione nei forum qui, ma sembra che altri proprietari di forum come @pearsonified siano stati gravemente inconvenienti. 18 ore di inattività, oof.
Le persone che parlano di ambienti di staging e di produzione sono fuori di testa. Ci sono molte persone non aziendali che ospitano forum Discourse su piccole VM. “Dovresti testare in un ambiente di staging” è una risposta offensiva e santimoniosa che non giustifica in alcun modo la rottura della loro installazione. Niente giustifica questo.
Voglio solo sottolineare che apprezzo che questo eccellente software sia completamente gratuito. Ne sono grato, e gli occasionali inciampi non cambiano i miei sentimenti.
Discourse è gratuito, server, domini e il nostro tempo non lo sono.
Questo non ha nulla a che fare con gli ambienti aziendali, è solo buon senso quando ci sono così tante variabili in gioco. Molto lavoro viene fatto per rendere gli aggiornamenti fluidi e se preferisci dedicare il tuo tempo gratuitamente per risolvere problemi significativi, a tuo rischio e pericolo, ma personalmente preferisco sapere che le comunità no-profit e di volontari che ospito saranno offline una volta per un aggiornamento indolore, invece che per un periodo prolungato.
Il VPS più piccolo di DO sarà sufficiente per ridurre il rischio di aggiornamenti, purché il test sia rappresentativo - se sei un buon SA, quei 5 dollari sono il costo di una tazza di caffè e una frazione della tua tariffa oraria di mercato.
La VM di stg dovrebbe contenere anche i dati del forum, il che raddoppierebbe i nostri costi di hosting. Comunque non è necessario, è un forum di videogiochi e un po’ di inattività (non 18 ore!) va bene. Nel peggiore dei casi, avevo uno snapshot della VM prima dell’aggiornamento, quindi avrei potuto semplicemente ripristinarlo.
Trovo comunque preoccupante il fatto che sia rimasto rotto per 4 giorni. Gli aggiornamenti che falliscono senza rollback dovrebbero innescare un vero momento di “santo cielo, questo deve essere risolto ORA”. Questa non dovrebbe essere un’affermazione controversa.
Ho anch’io ricevuto l’errore web-push Ruby. Forum normale, nessun plugin personalizzato.
web-push-3.0.0 richiede la versione ruby >= 3.0, che è incompatibile con la
versione corrente, 2.7.6
Ci sono stati momenti in precedenza in cui è stato detto che doveva essere aggiornato tramite riga di comando. Forse quell’opzione potrebbe essere abilitata ora per qualsiasi versione stia causando questo problema?
Modifica: Oh, in realtà lo dice!
Il problema è che quando si esegue un aggiornamento di docker_manager e poi si fa clic sulla scheda in alto anziché aggiornare la pagina. Quindi potrebbe essere modificato per aggiornare tramite HTTP anziché semplicemente cambiare schede con JS?