Haha, wie ich sagte, ich benutze es für etwas anderes, ich kann es nicht einfach abschalten. Sicherlich sollte es nicht so schwer sein, den Port zu ändern (berühmte letzte Worte, wie es scheint)
Ich schlage vor, dass Sie das in dem verlinkten Thema fragen. Nach kurzem Blick auf das Skript sieht es hartcodiert aus, aber ich könnte mich irren, das Skript könnte erstellt worden sein.
Mir ist auch das Hardcoding aufgefallen, aber es gibt auch Verweise auf eine Portkonfiguration in YML-Dateien sowie auf Umgebungsvariablen. Ich gebe das im Moment auf. Ich habe bereits viel zu viel Zeit für das investiert, was ich testen wollte.
Eine VM mit einem frischen Ubuntu 22.04 hochgefahren. Die Dev-Installation bricht ab: Install Discourse for development using Docker - #213 by nordize
Nicht mein Tag … aber definitiv auch keine Minuten (kein Wortspiel beabsichtigt). Danke für deine Zeit und tut mir leid, dass du sie auch verschwenden musstest.
@merefield kurze Frage: Gibt es eine schnellere Möglichkeit, Plugin-Code-Updates im Container zu erhalten, als d/shutdown_dev; d/boot_dev auszuführen, was ewig dauert und eine Menge Daten herunterlädt, da Docker-Images gezogen werden? Das jedes Mal zu tun, wenn ich eine Codezeile ändere, um sie im Browser zu testen, erscheint selbst für eine Docker-Umgebung völlig übertrieben.
Das Neustarten des Rails-Servers mit d/rails s sieht die Codeänderungen meines Plugins nicht.
Dies sollte nur notwendig sein, wenn Sie ein Plugin entfernen oder hinzufügen, nicht wenn Sie eine Codezeile ändern.
Wenn es sich bei dieser Zeile um Ruby oder CSS handelt, wird der neue Code per Hot-Load geladen. Wenn es sich um Ruby handelt, sollten Sie sehen, wie die Einhörner im Terminal neu starten, wenn ich mich recht erinnere.
Wenn es sich um JavaScript handelt, müssen Sie nur den Browser aktualisieren.
Ich hätte erwähnen sollen, dass mein Plugin ein Symlink ist und alle Änderungen erst wirksam werden, wenn man d/shutdown_dev; d/boot_dev ausführt (dies wird auch im Leitfaden erwähnt), aber ich hatte gehofft, es gäbe eine Problemumgehung über Docker selbst, da dies nur gemappte Dateien sein sollten. Ich werde vielleicht im anderen Thread nachfragen oder sehen, ob ich es als Problemumgehung modifizieren kann (oder keine Symlinks verwenden).
Das klingt für mich nicht richtig. Der Serverprozess startet einfach neu, genau wie bei einer Nicht-Docker-Installation. Symlinks sollten keinen Unterschied machen und sind der richtige Weg, um zu arbeiten. Ich habe keine Ahnung, warum Ihrer sich nicht so verhält …
Nun, probieren Sie es ruhig aus. Ich hätte es nicht gepostet, wenn ein Neustart von Rails und Ember ausgereicht hätte. Wie ich schon sagte, weist der Leitfaden auch darauf hin.
Gemäß der Anleitung sollten diese Neustartbefehle nur dann ausgeführt werden, wenn Sie die Plugin-Population ändern (z. B. durch Entfernen oder Hinzufügen eines gültigen Symlinks). Andernfalls sollte Rails Codeänderungen erkennen und seine Prozesse neu starten. Es ist möglicherweise möglich, dieses Verhalten in der Konfiguration zu deaktivieren, aber dies sollte der Standard sein.
Hier ist ein Beispiel für den automatisierten Neustart, wenn auch bei einer Nicht-Docker-Dev-Installation, aber das Verhalten sollte ähnlich sein:
[DEV]: Bearbeitete Dateien, die nicht automatisch geladen werden. Server wird neu gestartet...
- plugins/discourse-multilingual/extensions/post.rb
SERVER WIRD NEU GESTARTET
I, [2022-06-15T13:25:29.082415 #227981] INFO -- : reaped #\u003cProcess::Status: pid 228047 exit 0\u003e worker=0
I, [2022-06-15T13:25:29.082642 #227981] INFO -- : reaped #\u003cProcess::Status: pid 228048 exit 0\u003e worker=1
I, [2022-06-15T13:25:29.082788 #227981] INFO -- : reaped #\u003cProcess::Status: pid 228049 exit 0\u003e worker=2
I, [2022-06-15T13:25:29.082877 #227981] INFO -- : master complete
I, [2022-06-15T13:25:29.947587 #228661] INFO -- : Refreshing Gem list
Got TERM signal
Shutting down
Terminating quiet threads
Scheduler exiting...
Pausing to allow jobs to finish...
Bye!
Starting CSS change watcher
I, [2022-06-15T13:25:38.326511 #228661] INFO -- : listening on addr=0.0.0.0:3000 fd=25
Ich habe die Datei post.rb bearbeitet und gespeichert, der Rest ist automatisiert.
Entschuldigen Sie, ich habe derzeit keinen Zugriff auf meine Docker-basierte Entwicklungsmaschine, um zu bestätigen, dass dies auch bei der Docker-Installation der Fall ist, aber ich erinnere mich, dass dies so ist, es sei denn, etwas hat sich geändert.
Ich bilde mir das nicht ein, wissen Sie
und ich kann nicht viel damit anfangen, wenn mir gesagt wird, dass es funktionieren sollte
Ich habe diese Anleitung bis ins kleinste Detail auf einer neuen VM-Installation mit Ubuntu 22.04 befolgt.
- Das Verlinken des Plugins in den Unterordner discourse/plugins/ und das Ändern von JS-Code im Plugin wird nicht gesehen, es sei denn, ich mache d/shutdown_dev; d/boot_dev, obwohl ich d/rails s und d/ember-cli neu starte
- Das Kopieren des Plugins in den Unterordner discourse/plugins/ und das Ändern von JS-Code im Plugin wird gesehen, ohne d/shutdown_dev; d/boot_dev zu tun, aber nur durch Neustart von d/rails s und d/ember-cli
Versuchen Sie es gerne oben. Das betreffende Plugin ist discourse-math, das Ändern von Code in assets/initializers/javascript/* .js (beachten Sie, dass diese speziellen Plugin-Dateien seitlich geladen werden und nicht direkt vom Browser per GET aufgerufen werden; ich bin mir nicht sicher, ob das einen Unterschied macht, ich habe noch nicht zu tief gegraben, wie Discourse intern funktioniert).
p.s. Ich weiß, dass ich den Browser aktualisieren muss (Cache umgehen) … geben Sie mir etwas Kredit.
Aus erster Hand, sozusagen:
Das Problem ist also möglicherweise lokal bei Ihnen oder eine Regression im aktuellen Build, aber Letzteres erscheint unwahrscheinlich.
Ich gebe auf, du hast gewonnen. Wenn du es jemals selbst versuchst, lass es mich wissen.
Ich versuche sicherlich nicht, “zu gewinnen”, aber wir müssen zu einer grundlegenden Verständigung gelangen:
- Es soll bei Änderungen am Backend-Code automatisch neu gestartet werden.
d/shutdown_dev; d/boot_devsollte nur notwendig sein, wenn Sie die Plugin-Population ändern, nicht nur einzelne Codezeilen.
Dies sollte reduzieren, wo Sie nach Fehlern suchen müssen.
Ich habe gerade git pull ausgeführt und eine Änderung ausprobiert, sie startet neu, also ist es keine Build-Regression.
Das noch seltsamere daran ist für mich, dass es sich um eine Docker-Einrichtung handelt, bei der es tatsächlich schwieriger ist, das verpackte Verhalten unbeabsichtigt zu überschreiben, sodass es zuverlässiger sein sollte.
Ich werde dies ausprobieren, wenn ich nach Hause komme, auf meinem Docker-Build.
Ich verstehe, dass dies im Moment ein frustrierender und ärgerlicher Workflow ist, es würde mich sicherlich ärgern und frustrieren.
Wenn Sie Ihren Cache vollständig geleert haben, bin ich mir in diesem Stadium nicht sicher, was ich vorschlagen soll.
Beachten Sie, dass Initialisierer nur einmal ausgeführt werden, wenn Sie die Seite zum ersten Mal öffnen. Das Neustarten der Serverprozesse ist also unerheblich (und deckt nur den Backend-Code ab).
Ich führe die Entwicklertools immer mit deaktiviertem Cache aus, wenn ich Webanwendungen entwickle. Ich bin neu in Discourse-Code und -Tools, aber nicht in der (Web-)Entwicklung. Ich habe auch eine Frage im Leitfaden-Thread gepostet. Vorerst habe ich einfach das Plugin-Verzeichnis unter discourse/plugins/ kopiert, um den Ärger zu vermeiden.
Ich werde später heute etwas Ähnliches versuchen und mich wieder melden.
Soweit ich das aus den Browser-Aufrufen sehen kann, wird der JS-Code aus dem Initialisierer-JS über eval() (bei jedem Seitenaufruf) durch discourse-math.js nachgeladen, was eindeutig darauf hindeutet, dass eine serverseitige Komponente diesen JS-Code aus dem Initialisierer (den ich ändere) verarbeitet und zwischenspeichert. Daher muss dieser spezielle serverseitige Cacher dazu gebracht werden, ihn erneut zwischenzuspeichern … was nicht passiert, wenn das Plugin verknüpft ist, aber passiert, wenn es kopiert wird.
Ich bin mit der Discourse-Toolchain nicht vertraut (und wollte es aufgrund von Zeitmangel zu diesem Zeitpunkt nicht werden) … daher meine Reverse-Engineering-Versuche und Fragen.
non-docker dev:
Ich habe das gerade in einem Initialisierer ausprobiert, kein Neustart irgendeines Prozesses notwendig, nur das Aktualisieren des Browsers hat die Änderung im JS-Code übernommen … das war non-docker … das werde ich später versuchen
etwas später…
docker-dev:
OK, jetzt bin ich an meinem PC und habe die Docker-Lösung ausprobiert, für die ich eine komplett frische Installation durchgeführt habe, und ich sehe das gleiche Verhalten: Änderungen am Initialisierer funktionieren für mich, die Server laufen weiter und ich speichere einfach die Datei und aktualisiere den Browser, kein Neubau des Containers ist notwendig.
Also das gleiche Verhalten
(Ich habe das Discourse Locations Plugin als Beispiel verwendet.)
Bist du sicher, dass mit deinem Initialisierer alles in Ordnung ist?
Da es nach einem Neustart funktioniert, ja, da bin ich sicher. Um es zu 100 % zuverlässig reproduzieren zu können, könnten Sie das von mir erwähnte spezifische Plugin ausprobieren, es in der GUI aktivieren und die Katex-Option in der GUI auswählen, dann die von mir erwähnte Initialisierer-JS-Datei bearbeiten und dann einen Beitrag mit Latex-Code darin erstellen. Dieses Plugin ist möglicherweise speziell und lädt seinen JS-Initialisierer möglicherweise nur bei Bedarf, wenn der Beitrag Latex-Code enthält (so würde ich es tun, wenn ich Discourse entwerfen würde) … aber ich erwarte nicht, dass Sie Ihre Zeit mit diesem Problem verschwenden, noch versuche ich Sie davon zu überzeugen, dass ich mir die Dinge nicht ausdenke ![]()
Ja, guter Punkt.
Das ist sehr, sehr seltsam.
Mein einziger Vorschlag für den Moment ist, auf eine Nicht-Docker-Installation umzusteigen (was leider länger dauert
), und zu sehen, wie das läuft?
Es wäre gut, einige Rückmeldungen vom Team zu bekommen, was bei Ihnen schiefgehen könnte. Allerdings würde die Docker-Lösung sicherlich die Wahrscheinlichkeit unterschiedlichen Verhaltens hier verringern, da sie containerisiert und atomar ist ![]()