Haha, como eu disse, estou usando para outra coisa, não posso simplesmente desativá-lo. Certamente não deve ser tão difícil mudar a porta (famosas últimas palavras, ao que parece)
1 curtida
Sugiro que pergunte isso no tópico vinculado, pelo que vi brevemente desse script, ele parece codificado, mas posso estar errado, o script pode ser compilado.
Eu também notei as coisas codificadas, mas há referências a uma configuração de porta em arquivos yml, bem como variáveis de ambiente. Vou desistir disso por enquanto. Tempo demais já investido no que eu queria testar.
Criei uma VM com um Ubuntu 22.04 limpo. A instalação de desenvolvimento falha: Install Discourse for development using Docker - #213 by nordize
Não é o meu dia… mas definitivamente não são minutos (sem trocadilhos). Obrigado pelo seu tempo e desculpe por você também ter que desperdiçá-lo.
1 curtida
@merefield pergunta rápida: existe uma maneira mais rápida de obter atualizações de código de plugin no contêiner do que fazer d/shutdown_dev; d/boot_dev, que leva uma eternidade e baixa uma tonelada de dados ao puxar imagens do docker? Fazer isso toda vez que eu mudo uma linha de código para testar no navegador parece totalmente exagerado, mesmo para um ambiente dockerizado.
Reiniciar o servidor rails com d/rails s não vê as alterações de código do meu plugin.
Isso só deve ser necessário se você remover ou adicionar um plugin, não se alterar uma linha de código.
Se essa linha for Ruby ou CSS, ela recarregará o novo código. Se for Ruby, você deverá ver os unicórnios reiniciando no terminal, se bem me lembro.
Se for Javascript, basta atualizar o navegador.
Eu deveria ter mencionado que meu plugin está em um link simbólico, e quaisquer alterações não são refletidas a menos que você execute d/shutdown_dev; d/boot_dev (isso também é mencionado no guia), mas eu esperava que houvesse uma solução alternativa via docker, já que estes deveriam ser apenas arquivos mapeados. Posso perguntar no outro tópico ou ver se consigo modificá-lo como uma solução alternativa (ou não usar links simbólicos).
Isso não me parece certo. O processo do servidor simplesmente reinicia como acontece em uma instalação não-docker. Symlinks não deveriam fazer diferença e é a maneira apropriada de trabalhar. Não tenho ideia de por que o seu não está se comportando dessa maneira…
Bem, sinta-se à vontade para tentar. Eu não teria postado se reiniciar o rails e o ember fosse suficiente. Como eu estava dizendo, o guia também aponta isso.
Conforme o guia, executar esses comandos de reinicialização só deve ser necessário se você alterar a população de plugins (por exemplo, removendo ou adicionando um link simbólico válido). Caso contrário, o Rails deverá detectar as alterações de código e reiniciar seus processos. Pode ser possível desativar esse comportamento na configuração, mas esse deve ser o padrão.
Aqui está um exemplo da reinicialização automatizada, embora em uma instalação de desenvolvimento não dockerizada, mas o comportamento deve ser semelhante:
[DEV]: Arquivos editados que não são autoloaded. Reiniciando o servidor...
- plugins/discourse-multilingual/extensions/post.rb
REINICIANDO 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
Eu editei o arquivo post.rb e salvei, o resto é automatizado.
Desculpe, não tenho acesso à minha máquina de desenvolvimento baseada em docker onde estou no momento para confirmar se este é o caso na instalação dockerizada também, mas lembro que é, a menos que algo tenha mudado.
Não estou inventando, sabe? 
e não posso fazer muito com a informação de que deveria funcionar Segui esse guia à risca em uma nova instalação de VM com Ubuntu 22.04.
- Vincular o plugin na subpasta discourse/plugins/ e alterar o código JS no plugin não é visto a menos que eu faça d/shutdown_dev; d/boot_dev, apesar de reiniciar d/rails s e d/ember-cli
- Copiar o plugin na subpasta discourse/plugins/ e alterar o código JS no plugin é visto sem fazer d/shutdown_dev; d/boot_dev, mas apenas reiniciando d/rails s e d/ember-cli
Sinta-se à vontade para tentar o acima. O plugin em questão é discourse-math, alterando o código em assets/initializers/javascript/*.js (lembre-se que esses arquivos de plugin específicos são carregados posteriormente e não chamados via GET pelo navegador diretamente; não tenho certeza se isso faz diferença, ainda não investiguei muito a fundo como o Discourse funciona internamente).
p.s. Eu sei que preciso atualizar o navegador (ignorando o cache)… me dê algum crédito.
Da fonte oficial, por assim dizer:
Portanto, o problema é possivelmente local para você, ou alguma regressão na compilação atual, mas esta última parece improvável.
Desisto, você venceu. Se você tentar fazer isso sozinho, me avise.
Eu certamente não estou tentando “ganhar”, mas precisamos chegar a um nível básico de entendimento:
- ele deve reiniciar automaticamente em alterações de código do back-end.
d/shutdown_dev; d/boot_devsó deve ser necessário quando você altera a população de plugins, não apenas linhas individuais de código.
Isso deve reduzir onde você precisa procurar para consertar as coisas.
Acabei de fazer git pull e tentei uma alteração, ele reinicia, então não é uma regressão de build.
A parte ainda mais estranha para mim é que, sendo uma configuração docker, é realmente mais difícil substituir inadvertidamente o comportamento empacotado, então deveria ser mais confiável.
Vou tentar isso na minha build docker quando chegar em casa.
Agradeço que isso seja frustrante e irritante como um fluxo de trabalho no momento, certamente me irritaria e frustraria.
Se você limpou totalmente seu cache, não tenho certeza do que sugerir neste momento.
Note que os inicializadores só rodam uma vez quando você abre a página pela primeira vez. Portanto, o reinício dos processos do servidor é irrelevante (e cobre apenas o código do back-end).
Estou executando as ferramentas de desenvolvimento com o cache desabilitado sempre que desenvolvo aplicativos web. Sou apenas novo em código e ferramentas do Discourse, não em desenvolvimento (web). Postei uma pergunta no tópico do guia também. Por enquanto, apenas copiei o diretório do plugin em discourse/plugins/ para evitar o incômodo.
1 curtida
Tentarei algo semelhante mais tarde hoje e reportarei.
Pelo que consigo ver nas chamadas do navegador, o código JS do inicializador JS é carregado lateralmente através do discourse-math.js, via eval() (a cada abertura de página), o que sugere claramente que algum componente do lado do servidor está processando e armazenando em cache esse código JS do inicializador (que é o que estou alterando), e, portanto, é esse cache do lado do servidor em particular que precisa ser acionado para re-armazená-lo em cache… o que não acontece se o plugin for vinculado simbolicamente, mas acontece quando é copiado.
Não estou familiarizado (e não queria me familiarizar neste momento devido à falta de tempo) com a cadeia de ferramentas do Discourse… daí meu reengenharia reversa e perguntas.
1 curtida
non-docker dev:
Tentei isso agora em um inicializador, sem necessidade de reiniciar nenhum processo, apenas a atualização do navegador captou a alteração no código js… isso foi non-docker… tentarei isso mais tarde
algum tempo depois…
docker-dev:
Ok, agora cheguei ao meu PC e tentei a solução docker para a qual fiz uma instalação completamente nova, e estou vendo o mesmo comportamento: edições no inicializador funcionando para mim, deixando os servidores rodando e simplesmente salvando o arquivo e atualizando o navegador, nenhuma reconstrução do container é necessária.
Então, o mesmo comportamento
(Usei o plugin Discourse Locations como exemplo.)
Você tem certeza de que não há nada de errado com seu inicializador?
Dado que funciona após a reinicialização, sim, tenho certeza. Para uma reprodutibilidade 100% confiável, você pode tentar o plugin específico que mencionei, ativá-lo na GUI e escolher a opção Katex na GUI, em seguida, editar o arquivo JS inicializador que mencionei e, em seguida, fazer uma postagem com código Latex dentro; este plugin pode ser especial, possivelmente carregando seu inicializador JS dinamicamente apenas se a postagem contiver código Latex (foi o que eu faria se projetasse o Discourse) … mas não espero que você perca tempo com este problema, nem estou tentando convencê-lo de que não estou inventando as coisas
1 curtida
Sim, bom ponto.
Isso é muito, muito estranho.
Minha única sugestão por enquanto é mudar para uma instalação não-docker (que leva mais tempo para configurar, infelizmente 
) e ver como isso vai?
Seria bom ter alguma opinião da equipe sobre o que pode estar dando errado para você. No entanto, a solução docker certamente reduziria as chances de um comportamento diferente aqui, já que é conteinerizada e atômica 