Tenho uma instalação Docker padrão (editar: não de desenvolvimento) em /var/discourse. É possível usar um diretório de plugin local para carregar no Discourse em vez de vincular a um repositório remoto do github a partir do app.yml? Se sim, como?
Tentei dois métodos que pensei que deveriam funcionar:
Clonei discourse-math do github em /var/discourse/plugins/discourse-math. launcher rebuild não disse nada sobre discourse-math e não há discourse-math no mount do docker também, nem na GUI. Então, acho que a pasta plugins é ignorada?
Também tentei clonar em um diretório diferente fora de /var/discourse e criar um link simbólico para /var/discourse/plugins/discourse-math … mesmo resultado.
Clonei o repositório do github em /var/discourse-math.git e editei meu app.yml para dizer - git clone file:////var/discourse-math.git, mas então launcher rebuild reclamou fatal: '/var/discourse-math.git' does not appear to be a git repository … supostamente o launcher executa isso em um contêiner docker já? Executar manualmente cd /tmp \u0026\u0026 git clone file:////var/discourse-math.git funciona perfeitamente.
O diretório plugins está fora do contêiner docker e é montado.
Portanto, se você estiver executando seu discourse docker a partir de ~/discourse, poderá clonar seus plugins ou criar um link simbólico para ~discourse/plugins localmente.
Certo, sim, eu estava ciente da instalação de desenvolvimento, mas tenho uma instalação Docker padrão (ou seja, instalação não de desenvolvimento), então acho que minha pergunta ainda permanece: posso carregar um plugin de um diretório local ou apenas remotamente do GitHub via app.yml?
p.s. Estou bem ciente de que o fluxo “correto” é ter uma instalação de desenvolvimento e brincar lá. Eu queria uma maneira rápida e suja de modificar e testar um plugin em vez de passar por toda a dor de uma instalação e configuração de desenvolvimento.
A instalação de produção clonará os plugins para dentro do contêiner, portanto, isso não é adequado para o desenvolvimento local de plugins, pois para esse fluxo de trabalho você precisará fazer upload de suas alterações para o GitHub.
Minha sugestão é descartar essa configuração e usar uma das duas principais opções de desenvolvimento, Docker ou não-Docker.
Só para ter certeza que entendi corretamente: Você está se referindo a clonar plugins do github remoto, e não conseguir clonar de um diretório local, mesmo via github file:///? Imagino que launcher.sh nesse ponto seja executado em um contêiner e não no host, ou seja, clona do github enquanto está no contêiner, em vez de clonar do host para a pasta montada do host… o que me permitiria fazer git clone file:///....
Se você quiser transformar a instalação de produção em um Frankenstein capaz de acessar os diretórios montados localmente, você precisará alterar os scripts de compilação para conceder esse acesso. Você seria responsável por dar suporte a essas personalizações.
Na minha humilde opinião, você está apenas criando trabalho e fragilidade para si mesmo.
A instalação de desenvolvimento do Docker foi projetada precisamente para oferecer uma solução de baixa manutenção para o desenvolvimento eficiente de plugins locais, por favor, considere usá-la.
Eu sei, e você está certo, é claro. Foi para uma alteração simples para testar em um arquivo javascript de um plugin. Eu o editei diretamente no contêiner (/var/www/discourse/public/assets/plugins/discourse-math-.js), mas por algum motivo, minhas edições não são refletidas no navegador - o navegador vê o arquivo antigo, apesar de limpar o cache, presumivelmente porque os arquivos js do plugin são cacheados pelo nginx embutido ou algo assim (?).
Ficaria grato por uma dica de uma maneira de editar um arquivo js atual no contêiner (por mais estranho que pareça) e torná-lo visível pelo navegador.
Eu posso já ter entrado no território de "Não tive tempo de escrever uma carta curta"… Eu não tive tempo de seguir o caminho adequado de uma instalação de desenvolvimento e não esperava que fosse tão difícil modificar um arquivo js dentro do contêiner (pouco tempo para ler sobre como o Discourse armazena em cache os arquivos js de plugins para tornar minhas alterações visíveis no navegador), etc., etc.
É um arquivo js de um plugin existente (a saber, o inicializador) que quero modificar. Os componentes de tema não ajudam (a menos que eu o entenda mal)
Os componentes do tema são carregados por último, acredito, então substituirão o plugin.
Outra boa opção é simplesmente fazer um fork do plugin, cloná-lo localmente para emendar e testá-lo usando uma instalação dev local (;)). Uma vez satisfeito, confirme e envie para o seu fork e use o fork para produção.
No entanto, a solução de Componente de Tema tem a vantagem de que você não precisa manter um fork, o que pode se tornar uma dor à medida que o plugin pai evolui.
Não tenho certeza se um componente Theme ajuda quando preciso modificar um arquivo como este … esse arquivo (junto com outros), como entendi, passa pelo mapper etc., para produzir o arquivo /var/www/discourse/public/applets/plugins/discourse-math-\\u003cid\\u003e.js do container que o navegador carrega. Eu só preciso mudar o último, mas o navegador ainda vê o arquivo antigo, como se houvesse cache do lado do servidor.
A instalação de desenvolvimento local consome tempo e esforço, mas pode ser feita se tudo mais falhar. Eu não esperava que uma modificação “suja” de um plugin js fosse tão dolorosa. Também ainda não entendo por que minhas edições diretas não são visíveis no navegador, a menos que haja cache do lado do servidor no nginx do container (não sei por quê, dado que é um js).
De qualquer forma, o tempo que tive para investigar isso hoje acabou :(. Obrigado pela ajuda de qualquer forma!
Não consigo aprofundar muito nos detalhes do que você está tentando alcançar, mas para garantir que um inicializador seja executado após outro, use este parâmetro after:, exemplo:
As ferramentas de desenvolvimento evoluíram exatamente para esse propósito, então, se puder, use-as. A configuração do ambiente docker de desenvolvimento deve levar minutos, não horas, e você só precisará fazê-la uma vez, depois será útil para todos os tipos de propósitos posteriormente. Não se deixe tentar a usar a instalação de produção localmente apenas porque você está familiarizado com ela! Ela simplesmente não é configurada para esse propósito.
Chame-me de estúpido, mas como mudo a porta padrão 3000 para outra coisa? d/boot-dev --init falha, pois estou usando essa porta para outra coisa. Tentei -e UNICORN_PORT=4200. Os guias que vi não dizem nada sobre a porta. O arquivo thin.yml em config/cloud/cloud66/files também parece ser ignorado.
3000 é a porta do servidor Ruby e 4200 é a porta do Ember. Ambos os processos precisam estar em execução. Você acessa o site no navegador pela porta 4200. É melhor discutir a instalação do Docker de desenvolvimento no tópico do Docker de desenvolvimento?
Bem, d/boot_dev --init falha (Error starting userland proxy: listen tcp 127.0.0.1:3000: bind: address already in use.). Talvez eu investigue isso mais tarde. Obrigado pelo seu tempo. Eu gostaria que essas coisas fossem melhor documentadas.
Ela simplesmente não é configurada para esse propósito.