Olá,
Precisamos usar este novo recurso/funcionalidade para e-mail:
Como ele não foi mesclado (assumimos que um dia será), qual é a maneira recomendada de executar um Discourse em produção e incluir um PR em revisão?
Eu assumo que temos que evitar/não atualizar o Discourse para as atualizações regulares, mas isso provavelmente simplifica demais a abordagem.
Qualquer orientação sobre como outros trabalham nesse cenário seria apreciada.
Primeiro: Eu não sei.
Mas acho que isso pode funcionar:
cd /var/discourse
./launcher enter app
cd /var/www/discourse
su - discourse -c 'git fetch origin pull/<pr_number>/head:<local_branch_name>'
su - discourse -c 'git switch <local_branch_name>'
sv restart unicorn
Se isso funcionar, você pode adicionar coisas ao seu app.yml para fazer isso durante a compilação. Ou talvez seja mesclado em breve e você possa apenas esperar.
Se isso piorar as coisas, você pode fazer um
./launcher destroy app;./launcher start app
e isso restaurará a imagem que você compilou pela última vez.
Isso é muito útil, obrigado. Idealmente, gostaríamos de esperar até que seja mesclado, mas, sendo novo nisso, não está claro se isso levará alguns dias, semanas ou meses.
Obrigado novamente.
Nenhuma crítica a este PR (não olhei em detalhes), mas, em geral, não acho que esta seja uma boa prática.
Aproveite a revisão do desenvolvedor do CDCK e espere até que seja revisado e mesclado?
Esse é um bom conselho.
Com o que sugeri, você pode ser capaz de ver que realmente funciona (ou talvez haja especificações lá que respondam a essa pergunta), ou se virar por um tempo até que seja aceito. Muitas pessoas esperam semanas (ou meses) para atualizar de qualquer maneira.
@merefield obrigado - Acredito que você está dizendo para esperar até que seja mesclado, correto?
Concordamos, essa é uma ótima ideia. Enquanto isso, no entanto, precisamos lidar com os e-mails devolvidos.
Novamente, não sabemos quanto tempo o processo leva, então, sem esse conhecimento, assumiremos que levará um bom tempo.
Talvez eu esteja perdendo alguma nuance aqui…
Acho que você pode tentar por algumas semanas. Se houver outra versão, você pode decidir se atualiza seu PR para funcionar com a próxima versão ou encontra outra solução. Provavelmente, o mais fácil seria fazer isso em um plugin?
Espere. Por que não fazer isso em um plugin?
Esse é o curso de ação usual. Faça em um plugin e depois pergunte se eles estariam interessados em um PR. No momento, parece que você é o único no planeta que quer isso. Adicioná-lo ao core significa que alguém terá que mantê-lo indefinidamente; não é trivial.
Sim, eu não entendo por que isso não é implementado em um plugin.
Então você poderia simplesmente evoluir o plugin separadamente da instalação principal.
Uma vez (se) o PR for mesclado, você poderia então remover o plugin!
Também precisamos resolver este problema para patches de segurança não públicos.
Temos código em nossas ferramentas internas que mescla um branch de um repositório - eu recomendaria a mesma abordagem para você.
Algo como isto deve funcionar para você em um bloco exec (provavelmente no hook after_code):
# buscar e mesclar o patch
git merge REFERENCE --no-commit
bundle install # se necessário
pnpm install --frozen-lockfile # se necessário
@merefield @pfaffman não é um plugin simplesmente porque, para nós, isso não é trivial. Nunca escrevemos um plugin. Se alguém tiver algumas orientações sobre como conectar isso, ficaremos felizes em analisar!
Além disso, eu provavelmente não diria que somos a única pessoa que ‘quer’ netcore - é um dos maiores ESPs… na Terra, e muitas vezes maior do que alguns dos outros suportados no core. Não estou sugerindo que seja melhor, ou que os usuários possam querer os outros, mas netcore é um ESP muito grande e bem conceituado. Na verdade, você pode ver muitas discussões sobre isso aqui, pois era anteriormente pepipost:
Uma estratégia dupla seria apropriada, na minha opinião:
Não poder construir um plugin não é um bom motivo para PR.
Terceiros ainda poderiam usar seu plugin.
@merefield desculpe, por que você acha que a compilação do plugin está relacionada à criação do PR? O próprio Netcore escreveu o PR.
Talvez eu esteja perdendo algum detalhe no que você está dizendo.
Apenas uma sugestão. Isso lhe dá mais flexibilidade nos prazos de implantação. Quem não gosta de menos dependências?
Porque você pode criar um plugin.
Você não sabe se eles alguma vez aceitarão seu PR. E eu também não.
Aqui está uma dica: Alguém da Equipe respondeu neste tópico e eles não disseram “Sim, vamos aceitar isso o mais rápido possível”. Em vez disso, eles lhe deram “É isso que fazemos se tivermos um PR que não será aceito no núcleo por meses”.
Parece que essas são suas opções.
Eu não interpretaria tanto assim minha resposta.
Eu sou do lado de infraestrutura, não tenho informações sobre as prioridades das equipes de desenvolvimento. Para mim, o commit parece 
, mas um olhar mais experiente pode ter uma opinião diferente.
Mas eu acho que responder a essa pergunta seria um conselho / FAQ geralmente útil para auto-hospedeiros.
Na minha opinião, um plugin seria muito pesado aqui.
Bem, mostra o que eu sei.
E eu continuo esquecendo o quão grande é a equipe agora e o quão segmentadas as equipes devem ser. Parece que foi ontem que a maioria de todos sabia quase tudo (claro, mesmo assim as pessoas tinham seus nichos), mas esse “ontem” foi há oito anos.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.