Ho un’installazione Docker standard (modifica: non-dev) in /var/discourse. È possibile utilizzare una directory di plugin locale per caricarla in Discourse invece di collegarsi a un repository GitHub remoto da app.yml? Se sì, come?
Ho provato due metodi che pensavo dovessero funzionare:
Ho clonato discourse-math da GitHub in /var/discourse/plugins/discourse-math. launcher rebuild non ha detto nulla su discourse-math e non c’è discourse-math nemmeno nel mount Docker, né nell’interfaccia grafica. Quindi immagino che la cartella plugins venga ignorata?
Ho anche provato a clonare in una directory diversa fuori da /var/discourse e a collegarla simbolicamente a /var/discourse/plugins/discourse-math… stesso risultato.
Ho clonato il repository GitHub in /var/discourse-math.git e ho modificato il mio app.yml per dire - git clone file:////var/discourse-math.git ma poi launcher rebuild si è lamentato fatal: '/var/discourse-math.git' does not appear to be a git repository… presumibilmente il launcher esegue questo in un container Docker già? Eseguire manualmente cd /tmp \u0026\u0026 git clone file:////var/discourse-math.git funziona benissimo.
La directory plugins si trova all’esterno del container Docker e viene montata.
Quindi, se stai eseguendo il tuo Docker di Discourse da ~/discourse, puoi clonare i tuoi plugin o creare un collegamento simbolico in ~discourse/plugins localmente.
Sì, ero a conoscenza dell’installazione per sviluppatori, ma ho un’installazione Docker standard (cioè non per sviluppatori), quindi immagino che la mia domanda rimanga valida: posso caricare un plugin da una directory locale o solo da remoto da GitHub tramite app.yml?
p.s. Sono ben consapevole che il flusso “corretto” è avere un’installazione per sviluppatori e lavorarci. Volevo un modo rapido e sporco per modificare e testare un plugin invece di affrontare tutto il tormento di un’installazione e configurazione per sviluppatori.
Capito, la tua insolita configurazione mi ha confuso.
L’installazione di produzione clonerà i plugin nel container, quindi questo non è adatto allo sviluppo di plugin locali, poiché per quel flusso di lavoro dovrai caricare le tue modifiche su GitHub.
Il mio suggerimento è di abbandonare quella configurazione e utilizzare una delle due principali opzioni di sviluppo, Docker o non-Docker.
Solo per assicurarmi di averti capito correttamente: ti riferisci al fatto che clona plugin da github remoto e non è in grado di clonare da una directory locale, nemmeno tramite github file:///? Suppongo che launcher.sh a quel punto venga eseguito in un container e non nell’host, cioè clona da github mentre è nel container, invece di clonare dall’host nella cartella montata dell’host… il che mi permetterebbe di fare git clone file:///...
Se si desidera trasformare l’installazione di produzione in un Frankenstein in grado di accedere alle directory montate localmente, sarà necessario modificare gli script di build per concedere tale accesso. Sarà necessario assumersi la responsabilità di supportare autonomamente tali personalizzazioni.
A mio modesto parere, ti stai solo creando lavoro e fragilità.
L’installazione di sviluppo Docker è progettata appositamente per fornire una soluzione a bassa manutenzione per uno sviluppo efficiente di plugin locali, si prega di considerare di utilizzarla.
Lo so, e hai ragione, ovviamente. Era per una semplice modifica da testare in un file javascript di un plugin. L’ho modificato direttamente nel container (/var/www/discourse/public/assets/plugins/discourse-math-.js) ma per qualche motivo, le mie modifiche non vengono riflesse nel browser - il browser vede il vecchio file, nonostante la pulizia della cache, presumibilmente perché i file js del plugin sono memorizzati nella cache da nginx incorporato o qualcosa del genere (?).
Sarei grato per un consiglio su un modo per modificare un file js corrente nel container (per quanto possa sembrare imbarazzante) e renderlo visibile dal browser.
Potrei già essere finito nel territorio del tipo “Non ho avuto il tempo di scrivere una lettera breve”… Non ho avuto il tempo di seguire il percorso corretto di un’installazione per sviluppatori e non mi aspettavo che fosse così difficile modificare un file js all’interno del container (poco tempo per approfondire come Discourse memorizza nella cache i file js dei plugin per rendere visibili le mie modifiche nel browser), ecc. ecc.
È un file js di un plugin esistente (cioè l’inizializzatore) che voglio modificare. I componenti del tema non aiutano (a meno che non ti abbia capito male)
I componenti del tema vengono caricati per ultimi, credo, quindi sovrascriveranno il plugin.
Un’altra buona opzione è semplicemente fare un fork del plugin, clonarlo localmente per modificarlo e testarlo utilizzando un’installazione dev locale (;)). Una volta soddisfatti, esegui il commit e invialo al tuo fork e usa il fork per la produzione.
Tuttavia, la soluzione dei componenti del tema ha il vantaggio di non dover mantenere un fork che potrebbe diventare un problema man mano che il plugin padre si evolve.
Non sono sicuro che un componente Theme aiuti quando devo modificare un file come questo … quel file (insieme ad altri), per quanto ne so, passa attraverso il mapper ecc., per produrre il file /var/www/discourse/public/applets/plugins/discourse-math-\\u003cid\\u003e.js del container che il browser carica. Ho solo bisogno di cambiare quest’ultimo, ma il browser vede ancora il vecchio file, come se ci fosse una cache lato server.
L’installazione di sviluppo locale richiede tempo e fatica, ma potrei farlo se tutto il resto fallisce. Non mi aspettavo che una modifica “sporca” di un plugin js fosse così complicata. Inoltre, non capisco ancora perché le mie modifiche dirette non siano visibili nel browser, a meno che non ci sia una cache lato server nel nginx del container (non ho idea del perché dato che è un file js).
Comunque, il tempo che ho avuto oggi per occuparmi di questo è finito :(. Grazie comunque per l’aiuto!
Non posso approfondire troppo i dettagli di ciò che stai cercando di ottenere, ma per assicurarti che un inizializzatore venga eseguito dopo un altro, usa questo parametro after:, esempio:
I tool di sviluppo si sono evoluti proprio per questo scopo, quindi se puoi, usali. La configurazione dell’ambiente docker di sviluppo dovrebbe richiedere minuti, non ore, e dovrai farlo solo una volta, poi sarà utile per tutti i tipi di scopi successivi. Non lasciarti tentare dall’usare l’installazione di produzione localmente solo perché ti è familiare! Semplicemente non è configurata per tale scopo.
Chiamami stupido, ma come faccio a cambiare la porta predefinita 3000 in qualcos’altro? d/boot-dev --init fallisce perché sto usando quella porta per qualcos’altro. Ho provato -e UNICORN_PORT=4200. Le guide che ho visto non dicono nulla sulla porta. Anche il file thin.yml in config/cloud/cloud66/files sembra essere ignorato.
3000 è la porta del server Ruby e 4200 è la porta di Ember. Entrambi i processi devono essere in esecuzione. Accedi al sito nel browser tramite 4200. Meglio discutere l’installazione di Docker per lo sviluppo nell’argomento Docker per lo sviluppo?
Bene, d/boot_dev --init fallisce (Error starting userland proxy: listen tcp 127.0.0.1:3000: bind: address already in use.). Forse approfondirò la cosa più tardi. Grazie per il tuo tempo. Vorrei che queste cose fossero meglio documentate.
Semplicemente non è configurata per tale scopo.