Ich erhalte diese Meldung, wenn ich versuche, über die Benutzeroberfläche ein Upgrade durchzuführen:
Nach mehreren Git-Pulls und Neuerstellungen erhalte ich immer noch dieselbe Meldung. Irgendwelche Tipps?
Ich frage mich, ob ich das tun muss:
Dies ist für ein altes, gut etabliertes Forum.
Cc @pacharanero
War dies eine Standardinstallation? Könnte es etwas sein wie das Ausführen des Upgrades auf dem falschen Server? Ist der Rebuild fehlgeschlagen und Sie haben den alten Container neu gestartet? Ich habe keine besseren Vermutungen.
Sie sollten Ihr Betriebssystem auf dem neuesten Stand halten, wie im verlinkten Thema empfohlen, aber das steht in keinem Zusammenhang mit dem von Ihnen beschriebenen Problem.
Es hat mich manchmal verwirrt, wenn das GUI-Update nicht zurückzusetzen scheint und wir aufgefordert werden, uns per SSH anzumelden, selbst wenn dies gerade erst geschehen ist.
Es war eine Standardinstallation, aber die ursprüngliche Installation erfolgte bereits 2014, in den allerersten Tagen, als Discourse noch nicht lange aus der öffentlichen Beta-Phase heraus war.
user@server:/var/discourse$ docker -v
Docker version 19.03.13, build 4484c46d9d
Es gibt eine neuere Version von Docker, aber es ist üblich, dass die Version in Ubuntu ein wenig hinter der neuesten zurückbleibt.
Das Betriebssystem wird vollständig und regelmäßig aktualisiert.
Hmm. Es gibt eine Verzögerung nach dem Update, bevor Discourse prüft, ob der Container neu erstellt wurde, obwohl ich noch nie erlebt habe, dass dies den docker-manager beeinträchtigt hat.
Sie könnten Folgendes versuchen:
docker exec app bash -c 'rails runner AdminDashboardGeneralData.refresh_stats'
Aber es ist jetzt schon lange genug her, dass ich nicht glaube, dass dies Ihr Problem ist. Es kann aber nicht schaden.
Ich erinnere mich nicht an die Mindestversion von Docker, die unterstützt wird, aber ich glaube auch nicht, dass dies das Problem ist, zumindest wenn Sie nicht auf Ubuntu 16.04 sind.
Könnte es vielleicht an dem Branch liegen, auf dem wir laufen?
In containers/app.yml wählen wir explizit tests-passed aus.
Aber das ist natürlich das, was INNERHALB des Containers läuft. Würde es einen Unterschied machen, was der Standard-Branch außerhalb des Containers ist?
user@server:/var/discourse# git status
On branch master
Your branch is up to date with 'origin/master'.
Früher war master der Standard bei GitHub. Jetzt ist es main.
Okay. Ich schätze, du könntest versuchen
cd /var/discourse
git checkout main
Aber ich dachte nicht, dass du das explizit tun musst.
Was ist mit
cd /var/discourse
./launcher enter app
cd /var/www/discourse
git status
Dies bezieht sich natürlich auf discourse_docker:
:/var/discourse# git remote -v
origin https://github.com/discourse/discourse_docker.git (fetch)
origin https://github.com/discourse/discourse_docker.git (push)
Der Branch wurde im August 2021 umgeschaltet und liegt zum Zeitpunkt der Erstellung 49 Commits hinter main: GitHub - discourse/discourse_docker at master
Sie möchten also definitiv zum main-Branch wechseln?
Ich stimme jedoch @pfaffman zu, dass ich das nie explizit getan habe, also muss es ein Skript gegeben haben, das dies getan hat. Vielleicht geschieht dies beim nächsten Rebuild?
gibt zurück
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'.
Das sieht so aus, als wärst du auf dem neuesten Stand. Und du siehst immer noch die Seite „Upgrades deaktiviert“?
Ja. Ich habe mir ein anderes Discourse angesehen, das ich betreibe und das schon etwas älter ist, ebenfalls auf master läuft und ebenfalls die gleiche Seite “Upgrades deaktiviert” anzeigt.
Allerdings ist ein weiteres Discourse, das ich Mitte 2022 eingerichtet habe, ebenfalls auf master und zeigt den Update-Bildschirm wie gewohnt an!
Wenn wir eine Bestätigung erhalten können, dass das Ändern des Branches von discourse_docker auf main das Problem behebt, bin ich bereit, es auszuprobieren. Vielleicht auf einer Website, die nur ich benutze.
Das würde ungefähr mit der Zeit zusammenfallen, als ich bei einigen Discourses seltsames Verhalten bei Updates bemerkte. (Deshalb habe ich sie am Ende immer über SSH mit Ansible aktualisiert).
Das ist so ziemlich das, was ich auch immer mache, obwohl ich zunehmend das Ansible-Upgrade-Skript mit https://www.pfaffmanager.com/ hochfahre.
Okay, ich bin auf den Track main auf einer Discourse-Instanz umgestiegen, die ich nur als persönliches Notizbuch und Tagebuch usw. verwende.
Vor dem Wechsel habe ich master getrackt und die Admin-Upgrade-Seite war tatsächlich deaktiviert.
Beim Wechsel zum Tracken von main und nach dem Rebuild kann ich bestätigen, dass die Admin-Upgrade-Benutzeroberfläche wieder normal funktioniert.
Hmmm. Ich frage mich, ob das bedeutet, dass all diese alten Installationen ihren Branch ändern müssen. @Falco, vielleicht möchtest du dir das ansehen.
Der Launcher ändert den Branch automatisch von master zu main. Es klingt, als ob etwas den automatischen Wechsel blockiert hat, wie z. B. ausstehende Stash-Änderungen.
Wie wahrscheinlich ist das bei so vielen Instanzen?
Und was zum Teufel sind Stash-Änderungen?
Von wie vielen sprechen wir? Es gibt Tausende von Discourse-Installationen, und ich sehe keine Dutzende von Berichten über dieses Problem. Zumindest noch nicht 
Wenn jemand einen Server hat, der diesen Fehler derzeit reproduziert und ihn noch einen Tag lang beibehalten kann, antworten Sie bitte hier, damit wir dies weiter untersuchen können.
Hmmm. Das könnte etwas damit zu tun haben, @nathank. Ich habe ein paar operative Dateien (die nichts mit der Discourse-Codebasis zu tun haben) im selben Verzeichnis wie das Discourse Git-Repository. Wenn ./launcher versuchen würde, den Branch zu wechseln, würde Git einen Fehler ausgeben, der mich dazu zwingen würde, diese Änderungen zu stashen (oder zu committen).
Danke, @Falco. Ich werde weitere Nachforschungen anstellen. Es könnte sein, dass nur Discourse-Instanzen betroffen wären, bei denen Git aus irgendeinem Grund beim Versuch, den Branch zu wechseln, einen Fehler ausgibt.
Update: Ich glaube, dieses Problem mit einigen nicht nachverfolgten Dateien könnte das Problem gewesen sein.
Ich habe die Dateien entfernt und sichergestellt, dass der Befehl git checkout main erfolgreich war.
Dann habe ich ./launcher rebuild app ausgeführt und es scheint funktioniert zu haben.
Soweit ich das beurteilen kann, und wie @Falco oben angibt, glaube ich nicht, dass es tatsächlich notwendig ist, main im Discourse-Repository zu verfolgen. Wenn Sie ./launcher rebuild app ausführen, prüft das Skript selbst den korrekten Branch.
Ich hatte ein paar ältere Discourses, auf denen immer noch die Seite „Upgrades deaktiviert“ angezeigt wurde, obwohl ich sichergestellt hatte, dass
git checkout main
git pull
git checkout master
ohne Fehler funktionierten.
Und für diese habe ich diese Instanzen einfach weiterhin main verfolgen lassen und ./launcher rebuild app ausgeführt, und es war in Ordnung.