Ho ricevuto questo messaggio quando ho provato ad aggiornare tramite l’interfaccia utente:
Dopo diversi git pull e rebuild sto ancora ricevendo lo stesso messaggio. Qualche suggerimento?
Mi chiedo se devo fare questo:
Questo è per un forum vecchio e ben consolidato.
Cc @pacharanero
È stata un’installazione standard? Potrebbe essere qualcosa come eseguire l’aggiornamento sul server sbagliato? La ricostruzione è fallita e hai riavviato il vecchio container? Non ho altre ipotesi migliori.
Dovresti mantenere il tuo sistema operativo aggiornato come raccomandato nell’argomento che hai collegato, ma questo non è correlato al problema che descrivi.
Mi ha lasciato perplesso in alcune occasioni quando l’aggiornamento della GUI non sembrava essere reimpostato e ci indirizzava a fare l’SSH, anche quando questo è stato appena fatto.
È stata un’installazione standard, ma l’installazione originale risale al 2014, agli albori quando Discourse non era uscito da molto tempo dalla beta pubblica.
user@server:/var/discourse$ docker -v
Docker version 19.03.13, build 4484c46d9d
Esiste una versione più recente di Docker, ma è comune che la versione in Ubuntu sia un po’ indietro rispetto all’ultima.
Il sistema operativo è completamente e regolarmente aggiornato.
Hmm. C’è un ritardo dopo l’aggiornamento prima che Discourse verifichi se il container è stato ricostruito, anche se non ho mai saputo che ciò influenzi docker-manager.
Potresti provare questo:
docker exec app bash -c 'rails runner AdminDashboardGeneralData.refresh_stats
Ma è passato abbastanza tempo ormai, che non credo sia questo il tuo problema. Non può fare male, però.
Non ricordo la versione minima di docker supportata, ma non credo che sia nemmeno questo il problema, almeno se non sei su Ubuntu 16.04.
Potrebbe dipendere dal branch che stiamo eseguendo?
In containers/app.yml stiamo selezionando esplicitamente tests-passed
Ma ovviamente questo è ciò che viene eseguito ALL’INTERNO del container. Potrebbe avere importanza quale sia il branch predefinito all’esterno del container?
user@server:/var/discourse# git status
On branch master
Your branch is up to date with 'origin/master'.
Back in the day master era il default in GitHub. Ora è main.
Va bene. Immagino che potresti provare
cd /var/discourse
git checkout main
Ma non pensavo che dovessi farlo esplicitamente.
Cosa ne dici di
cd /var/discourse
./launcher enter app
cd /var/www/discourse
git status
Questo si riferisce a discourse_docker, ovviamente:
:/var/discourse# git remote -v
origin https://github.com/discourse/discourse_docker.git (fetch)
origin https://github.com/discourse/discourse_docker.git (push)
Il branch è stato cambiato nell’agosto 2021 ed è 49 commit indietro rispetto a main al momento della scrittura: GitHub - discourse/discourse_docker at master
Quindi vuoi assolutamente passare al branch main?
Tuttavia, sono d’accordo con @pfaffman e non l’ho mai fatto esplicitamente, quindi deve esserci stato uno script che lo ha fatto. Forse accadrà con la prossima ricostruzione?
restituisce
user@inside-container-app:/var/www/discourse# git status
Refresh index: 100% (30949/30949), done.
On branch tests-passed
Your branch is up to date with 'origin/tests-passed'.
Sembra che tu sia aggiornato. E stai ancora ricevendo la pagina Aggiornamenti disabilitati?
Sì. Ho dato un’occhiata su un altro Discourse che gestisco, che risale un po’, ed è anch’esso su master e presenta la stessa pagina “Aggiornamenti disabilitati”.
Detto questo, un altro Discourse che ho configurato a metà 2022 è anch’esso su master e presenta la schermata di aggiornamento normalmente!
Se riusciamo ad avere una conferma che cambiare il branch di discourse_docker per tracciare main risolverà il problema, allora sono pronto a provarci. Magari su un sito che uso solo io.
Ciò coinciderebbe approssimativamente con il momento in cui ho iniziato ad avere comportamenti strani su alcuni Discourse intorno al momento dell’aggiornamento. (Per questo motivo, ho finito per aggiornarli tutti tramite SSH ogni volta, usando Ansible).
È praticamente quello che faccio sempre anch’io, anche se sempre più spesso, aumento lo script di aggiornamento di Ansible con https://www.pfaffmanager.com/.
Ok, ho cambiato il tracciamento su main in un Discourse che uso solo come blocco note e diario personale, ecc.
Prima del cambio, stavo tracciando master e la pagina Admin Upgrade era effettivamente disabilitata.
Passando al tracciamento di main e ricostruendo, posso confermare che l’interfaccia utente di Admin Upgrade è tornata a funzionare normalmente.
Hmmm. Mi chiedo se ciò significhi che tutte quelle vecchie installazioni debbano cambiare il loro branch. @Falco, forse vuoi vederlo.
Il launcher cambia automaticamente il branch da master a main. Sembra che qualcosa stesse bloccando il passaggio automatico, come modifiche in sospeso nello stash.
Quanto è probabile che accada su così tante istanze?
E cosa diavolo sono le modifiche al deposito?
Di quanti stiamo parlando? Ci sono migliaia di Discourse in circolazione e non vedo decine di segnalazioni di questo problema. Almeno non ancora 
Se qualcuno ha un server che sta attualmente riproducendo questo bug e può mantenerlo tale per un altro giorno, per favore risponda qui in modo che possiamo indagare ulteriormente.
Hmmmm. Questo potrebbe avere a che fare con questo sulla nostra istanza @nathank
Ho un paio di file operativi (che non hanno nulla a che fare con il codebase di Discourse) nella stessa directory del repository Git di Discourse. Se ./launcher tentasse di cambiare branch, Git dovrebbe generare un errore, richiedendomi di mettere in stash queste modifiche (o di eseguirne il commit).
Grazie @Falco, farò ulteriori indagini. Potrebbe darsi che le uniche istanze di Discourse che sarebbero interessate siano quelle in cui Git genera un errore per qualsiasi motivo nel tentativo di cambiare branch.
Aggiornamento: Penso che questo problema con alcuni file non tracciati possa essere stato il problema.
Ho rimosso i file e mi sono assicurato che il comando git checkout main avesse successo.
Quindi ho eseguito ./launcher rebuild app e sembra aver funzionato.
Per quanto ne so, come afferma @Falco sopra, non credo che sia effettivamente necessario tracciare main nel repository Discourse. Quando esegui ./launcher rebuild app, lo script stesso effettuerà il checkout del branch corretto.
Avevo alcuni Discourse più vecchi che mostravano ancora la pagina Aggiornamenti Disabilitati nonostante avessi assicurato che
git checkout main
git pull
git checkout master
funzionassero senza errori.
E per questi ho semplicemente lasciato che quelle istanze seguissero main e ./auncher rebuild app e andava bene.