Ho un aggiornamento fallito e sto cercando di capire quale messaggio di errore ne sia la causa. Tutti gli aggiornamenti che ho fatto nell’ultimo anno o due sono falliti e hanno richiesto un sacco di tentativi per essere completati.
Ho notato questi messaggi di dipendenza peer non soddisfatte durante ogni aggiornamento fallito, ma poiché non c’era molta discussione al riguardo qui, e alla fine sono riuscito a caricare la nostra app, ho scelto di ignorarli fino ad ora.
Ecco un esempio:
warning " > @glint/environment-ember-loose@1.0.2" has unmet peer dependency "@glimmer/component@^1.1.2".
warning " > @glint/environment-ember-template-imports@1.0.2" has unmet peer dependency "ember-template-imports@^3.0.0".
warning " > @mixer/parallel-prettier@2.0.3" has unmet peer dependency "prettier@^2.0.0".
warning Resolution field "babel-plugin-ember-template-compilation@2.0.0" is incompatible with requested version "babel-plugin-ember-template-compilation@^2.0.1"
warning Resolution field "unset-value@2.0.1" is incompatible with requested version "unset-value@^1.0.0"
warning " > babel-plugin-debug-macros@0.4.0-pre1" has unmet peer dependency "@babel/core@^7.0.0".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/aws-s3@3.0.6" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/aws-s3-multipart@3.1.3" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/xhr-upload@3.1.1" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/aws-s3 > @uppy/xhr-upload@3.3.0" has incorrect peer dependency "@uppy/core@^3.2.1".
Questo con tutti i plugin tranne Docker Manager disattivati nel mio file app.yml.
La discussione più simile che ho trovato suggeriva che il problema della ricostruzione potrebbe essere dovuto al fatto che il nostro droplet è stato creato molti anni fa e che è lì che siamo indietro su tutte queste versioni, quindi la soluzione migliore è creare un nuovo droplet e migrare.
Non so perché i tuoi aggiornamenti non funzionino e credo che i messaggi che vedi non siano correlati: sono avvisi, non errori.
Che tipo di “smanettamenti”?
Reinstallare Discourse su un server nuovo di zecca è abbastanza facile e veloce (a seconda delle dimensioni del tuo forum, ovviamente), quindi potresti anche farlo, potrebbe risolvere il problema non identificato. Se fossi in te, mi piacerebbe sapere qual è il problema, però.
Bene, abbiamo un tag ripetuto in qualche modo e questo impedisce all’app di ricostruire, cosa che posso risolvere seguendo questa guida:
..ma non posso accedere all’app per risolverlo poiché non è in esecuzione e non si avvia né si ricostruisce.
Stavo pensando che potrebbe essere dovuto a quegli errori e al fatto che il nostro Docker e Ubuntu sono un po’ datati.
Suppongo che proverò ad avviare una nuova istanza di Discourse su un nuovo droplet, installare Discourse e poi ripristinare il nostro ultimo backup tramite riga di comando in modo da poter, si spera, correggere il tag ripetuto nel DB e ricaricare l’app.
Vorrei anche conoscere il motivo di questi avvisi, dopo averli visti ora la build fallisce anche.
111:M 25 Sep 2023 23:13:54.237 # Redis è ora pronto per uscire, arrivederci...
/usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:110:in `readlines': Interrupt
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:110:in `block in spawn'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:103:in `popen'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:103:in `spawn'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:80:in `block in run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:78:in `each'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:78:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/command.rb:8:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:152:in `block (2 levels) in run_commands'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:142:in `each'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:142:in `block in run_commands'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:141:in `each'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:141:in `run_commands'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:124:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/cli.rb:65:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/bin/pups:9:in `<top (required)>'
from /usr/local/bin/pups:25:in `load'
from /usr/local/bin/pups:25:in `<main>'
Ero sulla build stabile 3.1.1, ho modificato il file app.yml per includere il plugin data explorer e ora sta fallendo. Non faccio una ricostruzione completa da un po’, ho usato solo la console di amministrazione web per aggiornare discourse e non ho mai avuto problemi fino ad ora. Il sistema Ubuntu è aggiornato su tutti i pacchetti.
AGGIORNAMENTO: Ricostruirlo una seconda volta sembra aver risolto il problema, gli avvisi compaiono ancora ma si è ricostruito con successo. Sarebbe interessante sapere perché gli avvisi compaiono ora e il loro impatto (se presente).
Ci sono molti modi per risolvere questo problema prima che sfugga di mano. Normalmente puoi ricostruire o ricaricare un backup precedente e correggere il duplicato nell’area di amministrazione. Il mio è sfuggito di mano, ecco uno scenario peggiore per correggere manualmente il DB se dovesse mai succedere a te:
