Okay, wenn ich bereits ein gut entwickeltes Plugin im Entwicklungsmodus habe, wie bringe ich dieses Plugin dann in die Produktion, ohne auf Drittanbieter-Dienste zurückzugreifen? Gibt es dafür überhaupt eine Möglichkeit?
Ja, das wird in diesem Dokument erklärt
Meinst du das ernst? Das gesamte Tutorial basiert auf GitHub, und meine Frage zielt darauf ab, nicht auf Drittanbieter angewiesen zu sein.
Hoste es auf GitHub oder GitLab und klone es wie üblich.
Discourse selbst ist auf eine ganze Reihe externer Dienste angewiesen, wie GitHub, Docker Hub, Rubygems, das NPM-Registry und LetsEncrypt. Wenn du mich fragst, ergibt es wenig Sinn, die Plugin-Bereitstellung unabhängig von GitHub zu machen, wenn das System ansonsten weiterhin von diesen Diensten abhängt.
Oh, du hast recht, diesen Teil habe ich übersehen. 
Das ergibt Sinn, da ich viele kleine Plugins entwickelt habe, die nur kleine Aufgaben erfüllen und daher keine Updates benötigen. GitHub zu verwalten, um diese kleinen Plugins hochzuladen, ist übertrieben und zu viel Aufwand.
Ein Plugin auf GitHub zu veröffentlichen, dauert weniger als eine Minute. Erstelle ein Repository und kopiere das Shell-Skript, das nach der Erstellung ausgegeben wird, welches git init, git add und git push ausführt. Das ist der Grund, warum du die erste Person bist, die diese Frage stellt. Es ist außerdem eine gute Idee, deine Plugins unter Versionskontrolle zu halten, egal wie klein das Plugin ist.
Du könntest das Installationsskript kopieren und so modifizieren, dass es deine Plugin-Verzeichnisse direkt in das Docker-Image kopiert. Das setzt voraus, dass der Plugin-Code bereits lokal vorliegt. Allerdings vermute ich, dass die Wartung des modifizierten Installationsskripts im Vergleich zu den Updates, die es erhält, zehnmal mehr Arbeit ist.
Ich bin nicht der Erste, der das fragt (andere haben es schon getan), aber die Diskussion wird immer verwickelter, und am Ende antwortet ihr gar nicht wirklich.
Es gibt keine Begründung für diesen Ansatz, der keine Flexibilität zulässt. Probiert WordPress oder einen anderen Dienst wenigstens einmal aus, und ihr werdet sehen, dass das Installieren von Plugins nicht die Albtraum-Situation ist, die es bei Discourse ist.
GitHub zu nutzen ist in Ordnung, aber ist es verpönt, lokal arbeiten zu wollen?
Nur zur Klarstellung: Ich arbeite nicht für Discourse.org. Ich bin hier nur ein Nutzer, genau wie ihr.
Bei Communiteq haben wir unser eigenes Control-Panel entwickelt, das eine einfache Installation und Deinstallation von Plugins ermöglicht. Fun Fact: Es ersetzt GitHub nicht, sondern baut darauf auf.
Wenn ihr jemals ein WordPress-Plugin entwickelt (nicht nur installiert) hättet, würdet ihr das nie sagen, denn das ist jetzt ein Albtraum.
Die Nutzung einer ordnungsgemäßen Versionskontrolle erspart Ihnen später viel Ärger und Probleme. Sie schützt Ihr Plugin für die Zukunft und hilft, einen Prüfpfad für Updates zu führen.
Sie bietet eine modulare Möglichkeit, Zuständigkeiten zu trennen und die Komplexität zu reduzieren.
Sie ermöglicht es, Ihre Instanzen unabhängig voneinander zu verwalten, wodurch Server-Migrationen und Neuaufbauten erheblich vereinfacht werden.
Außerdem ist es der professionelle Ansatz.
Mich interessiert, wie du ein „gut entwickeltes
Ich weiß nicht, ob das Hosten auf Codeberg mit Discourse-Plugins funktionieren sollte. Wenn ja, sucht der OP wahrscheinlich genau danach.
Ich stimme der Kritik an der Nutzung von GitHub zu. Sie haben ~300.000 Repositories (im Zusammenhang mit DMCA) ohne vorherige Kommunikation entfernt, und die Methodik der CMU-Studie – bei der geprüft wurde, ob zuvor beobachtete Repos später gelöscht wurden – deutet darauf hin, dass eine Größenordnung mehr Repos über interne Durchsetzung entfernt wurden.
Allein die CMU-Studie fand ~14.000 gelöschte Repos in einer einzigen Fake-Star-Aktion, im Vergleich zu ~20.000–47.000 jährlich durch DMCA. Es gibt keine Gesamtmetriken, da diese Repositories nur 404-Fehler anzeigen.
Ich meine, es besteht kein tatsächliches Risiko für Discourse-Plugins, aber Farble ist jetzt ein Thema der nationalen Sicherheit, und wir wussten nicht, was in naher Zukunft passieren könnte, wenn jeder menschliche Beitrag durch Persona oder etwas Ähnliches verifiziert werden müsste.
Empfiehlt ihr also, dass das Discourse-Team von GitHub abwandert?
Es gibt mehrere Alternativen, und das ist in Ordnung. Nutzt sie, wenn ihr müsst, aber wenn ihr nicht bereit seid, ein bisschen Arbeit zu investieren, lasst es imho besser sein, Discourse zu betreiben.
Nennen Sie das nun konfrontativ? Es tut mir leid, aber es hat niemand gekämpft. Wahrscheinlich sind Sie einfach nur zu sensibel. Und es tut mir leid, wenn das konfrontativ klang.
Wie auch immer, um Ihre Frage zu beantworten: Ich habe es offensichtlich mit einem einmaligen GitHub-Konto gemacht, aber da diese so klein sind, muss ich sie nicht wirklich viel testen oder viel Code schreiben.
Ich habe sie bereits mit dem einmaligen Konto installiert und getestet, dass sie funktionieren. Auf lange Sicht möchte ich jedoch nicht jedes Mal, wenn ich eine Änderung vornehmen möchte, das Repository im Auge behalten müssen. Ich mache keinen Spaß, wenn ich sage, dass sie sehr klein sind. Zum Beispiel fügt einer davon einfach einen Button auf einer externen Seite der Startseite hinzu – und das war’s.
Es ist, als wolle man ein Auto kaufen, aber es einem nicht mehr zumuten zu wollen, die jährliche Hauptuntersuchung durchführen zu lassen.
Das ist einfach der Preis, den man für das öffentliche Hosten im offenen Web zahlt.
Ich bin mir sicher, wenn du möchtest, findest du einen Weg, die Installationsskripte zu modifizieren und sie von einem Ort auf deinem Server aus zu verlinken, aber es klingt nicht so, als würdest du Arbeit investieren wollen, und es wird deine Aufgabe sein, diese Lösung zu schreiben und zu unterstützen.
Wenn du das auf eine Theme-Komponente reduzieren kannst, kannst du es Heath Robinson ähnlich machen und discourse_theme verwenden, um von deinem lokalen Rechner auf deinen Server zu pushen, aber weine nicht, wenn dein lokaler Rechner abstürzt, verloren geht oder gestohlen wird und du deinen Code nicht wiederherstellen kannst (ohne dann herauszufinden, wie du eine Live-Kopie von deinem Server bekommst)
Noch einfacher, wenn Sie das discourse_theme-Gem nicht installieren möchten: Themes können als ZIP-Datei hochgeladen werden, und Sie können im Admin-UI direkt eine ganze Menge erstellen.
Und zur Wiederholung: Wenn Sie nicht mit Ruby arbeiten, benötigen Sie überhaupt kein Plugin. Ein Theme ist also wahrscheinlich das, wonach Sie suchen … kein Git erforderlich.
Guter Punkt! Aber der Vorteil von discourse_theme ist die sofortige Aktualisierung vor Ort, sodass du Änderungen schnell überprüfen kannst, ohne ein Update zu zippen und erneut hochladen zu müssen.
Klingt eher so, als wolle man ein Auto fahren, aber nie eine Tankstelle besuchen. „Ich schöpfte das Benzin einfach mit bloßen Händen in den Tank“. 
Wenn du GitHub zur Entwicklung der Plugins verwendet hast, ist die Nutzung als Installationsquelle trivial. Das Pushen von Änderungen in ein Repository ist weniger Aufwand, als aktualisierte Plugin-Dateien manuell auf einen Server zu übertragen.
Es klingt eher so, als würdest du versuchen, den Installationsprozess zu umgehen, um Plugins auf einer gehosteten Discourse-Installation bereitzustellen.