Ahah, come ho detto, lo sto usando per qualcos’altro, non posso semplicemente eliminarlo. Sicuramente non dovrebbe essere così difficile cambiare la porta (famose ultime parole a quanto pare)
1 Mi Piace
Ti suggerisco di chiedere questo sull’argomento collegato, dalla mia breve analisi di quello script sembra codificato in modo fisso, ma potrei sbagliarmi, lo script potrebbe essere compilato.
Ho notato anche le cose hardcoded, tuttavia ci sono riferimenti a una configurazione di porta nei file yml e anche alle variabili ENV. Per ora ci rinuncio. Ho già investito troppo tempo per quello che volevo testare.
Ho avviato una VM con una nuova Ubuntu 22.04. L’installazione per sviluppatori fallisce: Install Discourse for development using Docker - #213 by nordize
Non è la mia giornata… ma sicuramente non sono minuti (nessun gioco di parole). Grazie per il tuo tempo e mi dispiace che tu abbia dovuto sprecarlo anche tu.
1 Mi Piace
@merefield domanda veloce: c’è un modo più rapido per ottenere aggiornamenti del codice dei plugin nel container rispetto a fare d/shutdown_dev; d/boot_dev, che richiede un’eternità e scarica una tonnellata di dati poiché scarica le immagini docker? Farlo ogni volta che cambio una riga di codice per testare nel browser sembra assolutamente eccessivo anche per un ambiente dockerizzato.
Riavviare il server rails con d/rails s non vede le modifiche al codice del mio plugin.
Questo dovrebbe essere necessario solo se rimuovi o aggiungi un plugin, non se cambi una riga di codice.
Se quella riga è Ruby o CSS, caricherà a caldo il nuovo codice. Se è Ruby, dovresti vedere gli unicorni riavviarsi nel terminale, se ricordo bene.
Se è javascript, devi solo aggiornare il browser.
Avrei dovuto menzionare che il mio plugin si trova in un symlink e che qualsiasi modifica non viene riflessa a meno che non si esegua d/shutdown_dev; d/boot_dev (questo è anche menzionato nella guida), ma speravo ci fosse una soluzione tramite Docker stesso poiché si tratta solo di file mappati. Potrei chiedere nell’altro thread o vedere se riesco a modificarlo come soluzione alternativa (o non usare symlink).
Non mi sembra corretto. Il processo del server si riavvia semplicemente come fa in un’installazione non Docker. I symlink non dovrebbero fare alcuna differenza ed è il modo appropriato di lavorare. Non ho idea del perché il tuo non si comporti in questo modo…
Bene, sentiti libero di provarci. Non avrei pubblicato se riavviare rails ed ember fosse stato sufficiente. Come stavo dicendo, anche la guida lo sottolinea.
Come da guida, l’esecuzione di tali comandi di riavvio dovrebbe essere necessaria solo se si modifica la popolazione dei plugin (ad esempio, rimuovendo o aggiungendo un symlink valido). Altrimenti, Rails dovrebbe rilevare le modifiche al codice e riavviare i suoi processi. Potrebbe essere possibile disattivare questo comportamento nella configurazione, ma dovrebbe essere quello predefinito.
Ecco un esempio del riavvio automatico, sebbene su un’installazione di sviluppo non Docker, ma il comportamento dovrebbe essere simile:
[DEV]: Edited files which are not autoloaded. Restarting server...
- plugins/discourse-multilingual/extensions/post.rb
RESTARTING UNICORN
I, [2022-06-15T13:25:29.082415 #227981] INFO -- : reaped #<Process::Status: pid 228047 exit 0> worker=0
I, [2022-06-15T13:25:29.082642 #227981] INFO -- : reaped #<Process::Status: pid 228048 exit 0> worker=1
I, [2022-06-15T13:25:29.082788 #227981] INFO -- : reaped #<Process::Status: pid 228049 exit 0> 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
Ho modificato il file post.rb e ho salvato, il resto è automatico.
Mi dispiace, ma al momento non ho accesso alla mia macchina di sviluppo basata su Docker per confermare che questo sia il caso anche sull’installazione Docker, ma ricordo che lo è, a meno che qualcosa non sia cambiato.
Non me lo sto inventando, sai 
e non posso fare molto con il fatto che mi venga detto che dovrebbe funzionare Ho seguito quella guida alla lettera su una nuova installazione di VM con Ubuntu 22.04.
- Collegare il plugin nella sottocartella discourse/plugins/ e modificare il codice JS nel plugin non viene visualizzato a meno che non faccia d/shutdown_dev; d/boot_dev, nonostante il riavvio di d/rails s e d/ember-cli
- Copiare il plugin nella sottocartella discourse/plugins/ e modificare il codice JS nel plugin viene visualizzato senza fare d/shutdown_dev; d/boot_dev ma solo riavviando d/rails s e d/ember-cli
Sentiti libero di provare quanto sopra. Il plugin in questione è discourse-math, modificando il codice in assets/initializers/javascript/*.js (tieni presente che questi particolari file del plugin vengono caricati separatamente e non chiamati direttamente dal browser; non sono sicuro se ciò faccia la differenza, non ho ancora scavato troppo a fondo nel funzionamento interno di Discourse).
p.s. So che devo aggiornare il browser (ignorando la cache) … dammi un po’ di credito.
Dalla fonte diretta, per così dire:
Quindi il problema è forse locale per te, o qualche regressione nella build attuale, ma quest’ultima sembra improbabile.
Mi arrendo, hai vinto. Se mai ci proverai da solo, fammelo sapere.
Non sto certo cercando di “vincere”, ma dobbiamo raggiungere una base di comprensione:
- dovrebbe riavviarsi automaticamente in caso di modifiche al codice back-end.
d/shutdown_dev; d/boot_devdovrebbe essere necessario solo quando si modifica la popolazione dei plugin, non solo singole righe di codice.
Ciò dovrebbe ridurre dove devi guardare per risolvere i problemi.
Ho appena fatto un git pull e provato una modifica, si riavvia, quindi non è una regressione di build.
La parte ancora più strana per me è che, essendo una configurazione docker, è effettivamente più difficile sovrascrivere involontariamente il comportamento impacchettato, quindi dovrebbe essere più affidabile.
Proverò questo sulla mia build docker quando torno a casa.
Apprezzo che questo sia frustrante e fastidioso come flusso di lavoro al momento, certamente mi infastidirebbe e frustrerebbe.
Se hai svuotato completamente la cache, non sono sicuro di cosa suggerire a questo punto.
Nota che gli initializer vengono eseguiti solo una volta quando apri la pagina per la prima volta. Quindi il riavvio dei processi del server è irrilevante (e copre solo il codice back-end).
Eseguo Dev Tools con la cache disabilitata ogni volta che sviluppo applicazioni web. Sono nuovo solo al codice e agli strumenti di Discourse, non allo sviluppo (web). Ho anche pubblicato una domanda nel thread della guida. Per ora ho semplicemente copiato la directory dei plugin sotto discourse/plugins/ per evitare il problema.
1 Mi Piace
Ci proverò qualcosa di simile più tardi oggi e ti farò sapere.
Per quanto posso vedere dalle chiamate del browser, il codice JS dall’inizializzatore JS viene caricato lateralmente tramite discourse-math.js, tramite eval() (ad ogni apertura della pagina), il che suggerisce chiaramente che qualche componente lato server sta elaborando e memorizzando nella cache quel codice JS dall’inizializzatore (che è quello che sto modificando), e quindi è quel particolare memorizzatore lato server che deve essere attivato per memorizzarlo nuovamente… cosa che non accade se il plugin è collegato simbolicamente ma accade quando viene copiato.
Non ho familiarità (e non volevo familiarizzare in questo momento a causa della mancanza di tempo) con la toolchain di Discourse… da qui il mio reverse-engineering e le mie domande.
1 Mi Piace
non-docker dev:
L’ho provato proprio ora su un inizializzatore, non è stato necessario riavviare alcun processo, è bastato aggiornare il browser per rilevare la modifica nel codice js… questo era non-docker… ci proverò più tardi
un po’ più tardi…
docker-dev:
OK, ora sono sul mio PC e ho provato la soluzione docker per la quale ho eseguito un’installazione completamente nuova, e sto riscontrando lo stesso comportamento: le modifiche all’inizializzatore funzionano per me lasciando i server in esecuzione e salvando semplicemente il file e aggiornando il browser, non è necessario ricostruire il container.
Quindi lo stesso comportamento
(Ho usato il plugin Discourse Locations come esempio.)
Sei sicuro che non ci sia niente che non va nel tuo inizializzatore?
Dato che funziona dopo il riavvio, sì, ne sono sicuro. Per una riproducibilità affidabile al 100%, potresti provare il plugin specifico che ho menzionato, abilitandolo nella GUI e scegliendo l’opzione Katex nella GUI, quindi modificando il file JS initializer che ho menzionato, quindi creando un post con codice Latex all’interno; questo plugin potrebbe essere speciale, caricando forse il suo initializer JS al volo solo se il post contiene codice Latex (questo è quello che farei se progettassi Discourse)… ma non mi aspetto che tu perda tempo su questo problema, né sto cercando di convincerti che non sto inventando le cose
1 Mi Piace
Sì, buon punto.
È molto, molto strano.
Il mio unico suggerimento per il momento è passare a un’installazione non Docker (che purtroppo richiede più tempo per la configurazione 
) e vedere come va?
Sarebbe utile avere un parere dal team su cosa potrebbe andare storto per te. Tuttavia, la soluzione Docker ridurrebbe sicuramente le possibilità di un comportamento diverso qui, dato che è containerizzata e atomica 