Ok, quindi se ho già un plugin ben sviluppato in modalità di sviluppo, come posso spostarlo in produzione senza fare affidamento su servizi di terze parti? Esiste un modo per farlo?
Sì, è spiegato in questo documento
Ma sul serio? L’intero tutorial si basa su GitHub, e la mia domanda riguarda proprio il non affidarsi a terze parti.
Ospitalo su GitHub o GitLab, clona come al solito.
Discourse stesso dipende da diversi servizi esterni come Github, Docker Hub, Rubygems, il registro NPM e LetsEncrypt. A mio avviso, rendere indipendente dal punto di vista del deployment la distribuzione del tuo plugin da Github non ha molto senso.
Oh hai ragione, mi sono perso quella parte. 
Ha senso perché ho sviluppato molti piccoli plugin che fanno piccole cose e quindi non avranno bisogno di aggiornamenti; gestire GitHub per pubblicare questi piccoli plugin è eccessivo, è troppo lavoro.
Pubblicare un plugin su Github richiede meno di un minuto. Crea un repository e copia/incolla lo script shell che viene generato al momento della creazione, il quale esegue git init, git add e git push. Ecco perché sei il primo a porre questa domanda. È inoltre una buona idea tenere i propri plugin sotto controllo di versione, indipendentemente dalle dimensioni del plugin.
Potresti copiare lo script di installazione e modificarlo in modo che copi le directory del tuo plugin direttamente nell’immagine Docker. Questo presuppone che tu abbia già il codice del plugin localmente. Tuttavia, sospetto che mantenere aggiornato lo script di installazione modificato rispetto agli aggiornamenti futuri richieda 10 volte più lavoro.
Non sono il primo a chiedere (altri l’hanno già chiesto), ma la discussione diventa sempre più complicata e, alla fine, voi non rispondete mai realmente a nulla.
Non c’è alcuna giustificazione per questo approccio che non permetta flessibilità. Provate almeno WordPress o un altro servizio una volta, e vedrete che installare plugin non è l’incubo che è su Discourse.
Usare GitHub va bene, ma è malvisto voler lavorare in locale?
Solo per chiarire: non lavoro per Discourse.org. Sono solo un utente qui, proprio come voi.
Da Communiteq abbiamo sviluppato il nostro pannello di controllo che permette un’installazione e disinstallazione dei plugin molto semplice. Curiosità: non sostituisce GitHub, ma si basa su di esso.
Se aveste mai sviluppato (non solo installato) un plugin per WordPress, non avreste mai detto questo, perché ora questo è un incubo.
Utilizzare un adeguato controllo di versione ti risparmierà molti dolori di testa e problemi in futuro. Mantiene il tuo plugin sicuro per il futuro e aiuta a conservare una traccia di audit degli aggiornamenti.
Fornisce un modo modulare per separare le responsabilità, riducendo la complessità.
Ti permette di gestire le tue istanze in modo indipendente, rendendo le migrazioni e i rebuild dei server molto più semplici.
È inoltre l’approccio professionale.
Mi incuriosisce come tu abbia creato e testato un plugin “ben sviluppato” senza utilizzare GitHub o un altro servizio di repository simile. Come hai sviluppato “molti piccoli plugin” per Discourse?
Essere combattivo con chi cerca di aiutarti non ti porterà da nessuna parte. Se hai già sviluppato plugin, come dici di aver fatto, saprai che installarli su Discourse non è un incubo; utilizzare un repository e modificare un file app.yml dovrebbe essere semplice per qualcuno che gestisce un hosting autonomo ed è esperto nello sviluppo di plugin.
Non so se l’hosting su Codeberg funzioni con i plugin di Discourse. Se funziona, probabilmente è quello che cerca l’autore originale.
Concordo nel mettere in discussione l’uso di GitHub. Hanno rimosso circa 300.000 repository (per motivi legati al DMCA) senza preavviso, e la metodologia dello studio della CMU — che verifica se i repository precedentemente osservati sono stati successivamente eliminati — suggerisce che un ordine di grandezza superiore di repository sia stato rimosso tramite enforcement interno.
Solo lo studio della CMU ha rilevato circa 14.000 repository eliminati in un’unica ondata di fake-star, rispetto alle 20.000–47.000 rimosse annualmente tramite DMCA. Non esistono metriche totali perché tali repository restituiscono solo errori 404.
Insomma, non c’è un rischio concreto per i plugin di Discourse, ma ora Farble è considerata una questione di sicurezza nazionale, e non sappiamo cosa potrebbe accadere nel prossimo futuro se ogni post umano dovesse essere sottoposto a verifica dell’identità (KYC) tramite Persona o strumenti simili.
Quindi consiglii al team di Discourse di abbandonare GitHub?
Esistono diverse alternative e va bene così. Usale se devi, ma se non sei disposto a impegnarti un po’ in più, secondo me non vale la pena gestire Discourse.
È questo che chiami combattivo? Mi dispiace, ma nessuno ha combattuto, probabilmente sei solo troppo sensibile. E mi scuso se è sembrato combattivo.
Comunque, per rispondere alla tua domanda, l’ho ovviamente fatto con un account GitHub temporaneo, ma sono così piccoli che non devo davvero testarli molto o scrivere molto codice.
Li ho già installati usando l’account temporaneo e ho verificato che funzionino, ma a lungo termine non voglio dover tenere d’occhio il repository ogni volta che voglio apportare una modifica. Non sto scherzando quando dico che sono molto piccoli. Ad esempio, uno di essi aggiunge semplicemente un pulsante a una pagina esterna nella home page, e basta.
È come dire che vuoi un’auto, ma non hai voglia di farti fare la revisione annuale.
È semplicemente il costo da pagare quando si ospita un servizio pubblicamente sul web aperto.
Sono sicuro che, se vuoi, puoi trovare un modo per modificare gli script di installazione e collegarli tramite symlink da una posizione qualsiasi del tuo server, ma non sembri avere intenzione di impegnarti nel lavoro: sarà tua responsabilità scrivere e supportare quella soluzione.
Se riesci a ridurlo a un Tema Component, puoi ricorrere a una soluzione all’antica stile Heath Robinson e usare discourse_theme per inviare i file dalla tua macchina locale al server, ma non lamentarti se la tua macchina locale si guasta, viene smarrita o rubata e non riesci a recuperare il codice (dovresti allora capire come ottenere una copia live dal tuo server).
Ancora più semplice se non vuoi installare il gem discorsetheme: i temi possono essere caricati come file zip e puoi costruire molto direttamente nell’interfaccia di amministrazione.
E per ribadire: a meno che tu non stia lavorando con Ruby, non hai affatto bisogno di un plugin, quindi probabilmente ciò che stai cercando è un tema… niente git necessario.
Ottimo punto! Ma il vantaggio di discourse_theme è il modo istantaneo in cui aggiorna in loco, così puoi verificare rapidamente le modifiche senza dover comprimere un aggiornamento e ricaricarlo.
Sounds more like wanting to drive a car but never visit a gas station. “I’ll just scoop the gas into the tank using my bare hands”. 
If you used GitHub to develop the plugins then using it as a source for installation is trivial. Pushing changes to a repo is less effort than transferring updated plugin files manually to a server.
It sounds more like you’re trying to bypass the installation process to deploy plugins on a Hosted Discourse installation.