Wie kann ich Discourse neu aufbauen, ohne die Version zu ändern?

Ich muss die SMTP-Einstellungen in app.yml aktualisieren, möchte aber die Version von Discourse nicht ändern.

Wenn ich eine Version über das Version-Tag angebe, schlägt der Neuaufbau mit dem folgenden Fehler fehl. Ich befinde mich derzeit in Version 2.4.0.beta8.

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && find /var/www/discourse ! -user discourse -exec chown discourse {} \+ failed with return #<Process::Status: pid 336 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"web", "cmd"=>["gem update bundler", "find $home ! -user discourse -exec chown discourse {} \\+"]}
6269af00c2a4671a6fd2cb13a55bd475743205262bae7f483bf468e4dcacbeed
** FAILED TO BOOTSTRAP ** bitte nach oben scrollen und nach früheren Fehlermeldungen suchen, es kann mehr als eine geben.
./discourse-doctor kann helfen, das Problem zu diagnostizieren.

Das taucht jedes Jahr auf und sollte wahrscheinlich einen #howto-Beitrag haben. Ich habe einfach nach spezifischer Version gesucht:

Ja, der Unterschied hier ist, dass ich das Version-Tag in der YAML-Datei verwende, aber beim erneuten Erstellen einen Fehler erhalte.

Wenn Sie nur die SMTP-Einstellungen ändern müssen, können Sie Folgendes tun:

./launcher destroy app 
./launcher start app

Ok, das liest also das YAML auch, wenn es nicht neu aufgebaut wird, klingt gut. Während das mein dringendes Problem löst, bin ich immer noch daran interessiert, warum die Version nicht funktioniert.

Du hast gesagt, dass du „einen Fehler

Ja, ich sehe, dass die Informationen, die ich im Beitrag gegeben habe, nicht detailliert genug waren. Ich denke nicht, dass es sich um einen Formatierungsfehler handelt, da die YAML-Datei ohne das Version-Tag einwandfrei funktioniert.

Ich habe einige weitere Tests durchgeführt, und es scheint, dass der Fehler, auf den ich gestoßen bin, in den Versionen 10 und 11 nicht auftritt, aber in den Versionen 4 bis 9 ausgelöst wird.

Ich kann nur zwei Fehler im Druckausdruck finden, und ich denke, diese sind zu erwarten:

2020-02-22 10:42:33.410 UTC [62] postgres@postgres ERROR:  database "discourse" already exists

2020-02-22 10:42:33.533 UTC [73] postgres@discourse ERROR:  role "discourse" already exists

Ich habe die Versionshinweise für Version 10 durchgesehen und keinen Hinweis auf eine diesbezügliche Korrektur gefunden.

Es ist gut, dass es behoben ist, und mit deiner Workaround-Lösung für die SMTP-Einstellungen (ich werde sie am Montag testen, ich möchte den Produktionsserver am Wochenende nicht stören) besteht für mich kein dringender Bedarf. Es wäre jedoch gut zu wissen, ob es einen unbekannten Fehler gibt, den die Tests nicht erkennen und der zurückkehren könnte, wenn er „zufällig

Ich habe endlich Zeit gefunden, dies zu testen, und es hat nicht funktioniert. Ich sehe, dass das richtige Passwort beim Start der App ausgegeben wird, aber E-Mails scheitern weiterhin aufgrund von „Zugriff verweigert“.

Hmm. Ich bin mir sicher, dass es früher funktioniert hat. Ich habe gesehen, dass einige andere Einstellungen nicht in die Konfigurationsdatei übernommen wurden. Ich bin mir nicht sicher, ob das als Fehler gilt.

Es könnte auch sein, dass ich eine ältere Version verwende, sodass es in der neuesten Version möglicherweise funktioniert oder auch nicht. Ich wollte nur mit meinen Erkenntnissen aktualisieren.

Ich musste mich wieder damit befassen. Es scheint, als würde die Versionsnummer für Branches funktionieren, aber nicht für Tags. Ich vermute, das liegt daran, dass der Launcher nicht zuerst alle Tags herunterlädt, aber ich bin mir nicht sicher. Gibt es eine Möglichkeit, die Launcher-Skripte zu bearbeiten?

Endlich habe ich herausgefunden, was schiefgeht: Das discourse_docker-Repository und das discourse-Repository sind voneinander abhängig, sodass eine bestimmte Version von discourse nur mit einer bestimmten Version des discourse_docker-Repositories installiert werden kann. Leider gibt es im discourse_docker-Repository keine Tags, sodass es nicht einfach ist, herauszufinden, welche SHA für die Installation einer bestimmten Version verwendet werden soll. Schön, dass ich zumindest jetzt Klarheit habe. Ich werde mir ab sofort Notizen für meine zukünftigen Installationen machen.