Ich habe eine Standard-Docker-Installation (Bearbeitung: keine Entwicklerversion) in /var/discourse. Ist es möglich, ein lokales Plugin-Verzeichnis zu verwenden, um es in Discourse zu laden, anstatt aus app.yml auf ein entferntes GitHub-Repository zu verweisen? Wenn ja, wie?
Ich habe zwei Methoden ausprobiert, von denen ich dachte, dass sie funktionieren sollten:
Ich habe discourse-math von GitHub in /var/discourse/plugins/discourse-math geklont. launcher rebuild sagte nichts über discourse-math und es gibt weder im Docker-Mount noch in der GUI ein discourse-math. Ich vermute also, dass der plugins-Ordner ignoriert wird?
Ich habe auch versucht, in ein anderes Verzeichnis außerhalb von /var/discourse zu klonen und es mit einem Symlink nach /var/discourse/plugins/discourse-math zu verknüpfen … gleiches Ergebnis.
Ich habe das GitHub-Repository in /var/discourse-math.git geklont und meine app.yml so bearbeitet, dass sie - git clone file:////var/discourse-math.git lautet, aber dann beschwerte sich launcher rebuild mit fatal: '/var/discourse-math.git' does not appear to be a git repository … angeblich führt der Launcher dies bereits in einem Docker-Container aus? Das manuelle Ausführen von cd /tmp \u0026\u0026 git clone file:////var/discourse-math.git funktioniert einwandfrei.
Das Verzeichnis plugins befindet sich außerhalb des Docker-Containers und wird gemountet.
Wenn Sie also Ihren Discourse-Docker-Container von innerhalb von ~/discourse ausführen, können Sie Ihre Plugins lokal in ~discourse/plugins klonen oder verlinken.
Ja, ich war mir der Dev-Installation bewusst, aber ich habe eine Standard-Docker-Installation (d. h. keine Dev-Installation). Daher steht meine Frage immer noch: Kann ich ein Plugin aus einem lokalen Verzeichnis sideloaden oder nur remote von GitHub über app.yml?
p.s. Mir ist der „korrekte“ Ablauf bewusst, nämlich eine Dev-Installation zu haben und dort zu spielen. Ich wollte eine schnelle und schmutzige Methode, um ein Plugin zu modifizieren und zu testen, anstatt den gesamten Aufwand einer Dev-Installation und -Einrichtung auf sich zu nehmen.
Verstanden, Ihre ungewöhnliche Einrichtung hat mich verwirrt.
Die Produktionsinstallation klont Plugins in den Container, daher ist dies nicht für die lokale Plugin-Entwicklung geeignet, da Sie für diesen Workflow Ihre Änderungen auf GitHub hochladen müssen.
Mein Vorschlag ist, diese Einrichtung zu verwerfen und eine der beiden Hauptentwicklungsoptionen zu verwenden: Docker oder Nicht-Docker.
Nur um sicherzugehen, dass ich Sie richtig verstanden habe: Sie beziehen sich auf das Klonen von Remote-GitHub-Plugins und nicht auf das Klonen aus einem lokalen Verzeichnis, selbst über GitHub file:///? Ich nehme an, dass launcher.sh zu diesem Zeitpunkt in einem Container und nicht auf dem Host ausgeführt wird, d. h. es klont von GitHub, während es sich im Container befindet, anstatt vom Host in den gemounteten Ordner des Hosts zu klonen … was mir erlauben würde, file:///… zu klonen.
Wenn Sie die Produktionsinstallation in ein Frankenstein-Monster verwandeln möchten, das auf lokal gemountete Verzeichnisse zugreifen kann, müssen Sie die Build-Skripte ändern, um ihm diesen Zugriff zu gewähren. Sie wären selbst dafür verantwortlich, diese Anpassungen zu unterstützen.
Meiner bescheidenen Meinung nach schaffen Sie sich nur Arbeit und Instabilität.
Die Docker-Entwicklungsinstallation wurde genau dafür entwickelt, Ihnen eine wartungsarme Lösung für die effiziente lokale Plugin-Entwicklung zu bieten. Bitte erwägen Sie, diese zu nutzen.
Ich weiß, und Sie haben natürlich Recht. Es war für eine einfache Änderung zum Testen in einer JavaScript-Datei eines Plugins. Ich habe sie direkt im Container bearbeitet (/var/www/discourse/public/assets/plugins/discourse-math-.js), aber aus irgendeinem Grund werden meine Änderungen im Browser nicht angezeigt – der Browser sieht die alte Datei, trotz Cache-Bereinigung, vermutlich weil die Plugin-JS-Dateien vom eingebetteten Nginx oder so zwischengespeichert werden (?).
Ich wäre dankbar für einen Tipp, wie ich eine aktuelle JS-Datei im Container bearbeiten (so abgedroschen es auch klingen mag) und sie für den Browser sichtbar machen kann.
Ich bin vielleicht schon im Territorium “Keine Zeit, einen kurzen Brief zu schreiben” gelandet … Ich hatte keine Zeit, den richtigen Weg einer Entwicklerinstallation zu gehen, und ich hatte nicht erwartet, dass es so schwierig sein würde, eine JS-Datei im Container zu modifizieren (wenig Zeit, um mich darüber zu informieren, wie Discourse Plugin-JS-Dateien zwischenspeichert, um meine Änderungen im Browser sichtbar zu machen) usw. usw.
Es ist eine js-Datei eines bestehenden Plugins (nämlich des Initialisierers), die ich modifizieren möchte. Theme-Komponenten helfen nicht (es sei denn, ich missverstehe Sie).
Theme-Komponenten werden meiner Meinung nach zuletzt geladen und überschreiben daher das Plugin.
Eine weitere gute Option ist, das Plugin einfach zu forken, es lokal zu klonen, um es zu ändern und zu testen, indem Sie eine lokale dev-Installation verwenden (;)). Sobald Sie zufrieden sind, committen und pushen Sie es in Ihren Fork und verwenden Sie den Fork für die Produktion.
Die Lösung mit der Theme-Komponente hat jedoch den Vorteil, dass Sie keinen Fork pflegen müssen, was mühsam werden kann, wenn sich das übergeordnete Plugin weiterentwickelt.
Ich bin mir nicht sicher, ob eine Theme-Komponente hilft, wenn ich eine Datei wie diese modifizieren muss: dies … diese Datei (zusammen mit anderen) wird, soweit ich weiß, durch den Mapper usw. geleitet, um die Datei /var/www/discourse/public/applets/plugins/discourse-math-\\u003cid\\u003e.js des Containers zu erzeugen, die der Browser lädt. Ich muss nur letztere ändern, aber der Browser sieht immer noch die alte Datei, als ob es serverseitiges Caching gäbe.
Die lokale Entwicklungsinstallation ist zeit- und müheaufwendig, aber vielleicht mache ich das, wenn alles andere fehlschlägt. Ich hatte nicht erwartet, dass eine schmutzige Modifikation einer Plugin-JS so schmerzhaft sein würde. Ich verstehe auch immer noch nicht, warum meine direkten Bearbeitungen im Browser nicht sichtbar sind, es sei denn, es gibt serverseitiges Caching im Nginx des Containers (keine Ahnung warum, da es sich um eine JS handelt).
Wie auch immer, die Zeit, die ich heute dafür aufwenden musste, ist vorbei :(. Danke trotzdem für die Hilfe!
Ich kann nicht zu sehr ins Detail gehen, was Sie erreichen möchten, aber um sicherzustellen, dass ein Initialisierer nach einem anderen ausgeführt wird, verwenden Sie diesen after:-Parameter, Beispiel:
Die Entwickler-Tools haben sich genau für diesen Zweck weiterentwickelt. Wenn Sie also können, nutzen Sie sie. Die Einrichtung der Docker-Entwicklungsumgebung sollte Minuten und nicht Stunden dauern, und Sie müssen sie nur einmal einrichten, danach ist sie für alle möglichen Zwecke nützlich. Lassen Sie sich nicht dazu verleiten, die Produktionsinstallation lokal zu verwenden, nur weil Sie damit vertraut sind! Sie ist einfach nicht für diesen Zweck konfiguriert.
Nenn mich dumm, aber wie ändere ich den Standardport 3000 in etwas anderes? d/boot-dev --init schlägt fehl, da ich diesen Port für etwas anderes verwende. Ich habe -e UNICORN_PORT=4200 ausprobiert. Die Anleitungen, die ich gesehen habe, sagen nichts über den Port. Die Datei thin.yml in config/cloud/cloud66/files scheint ebenfalls ignoriert zu werden.
3000 ist der Ruby-Server-Port und 4200 ist der Ember-Port. Beide Prozesse müssen laufen. Sie greifen über 4200 im Browser auf die Seite zu. Besser die Dev-Docker-Installation im Dev-Docker-Thema besprechen?
Nun, d/boot_dev --init schlägt fehl (Error starting userland proxy: listen tcp 127.0.0.1:3000: bind: address already in use.). Vielleicht nehme ich das später weiter. Danke für Ihre Zeit. Ich wünschte, diese Dinge wären besser dokumentiert.
Sie ist einfach nicht für diesen Zweck konfiguriert.