Sou responsável por uma instalação do Discourse baseada em Docker, rodando em Ubuntu, que herdei como parte de um projeto de código aberto. Durante anos, eu a atualizava via git pull && ./launcher rebuild app e, em seguida, pela interface administrativa em /admin/update. No entanto, parei de fazer atualizações tão casualmente após uma experiência dolorosa durante uma atualização que causou quebras, relacionada ao docker_manager, em janeiro de 2024 (veja os comentários no commit aqui e o commit revertido aqui).
Já se passaram 2,5 anos e preciso retomar o ritmo de atualizações, mas ainda estou um pouco nervoso devido à última atualização que causou problemas. O que eu gostaria de ajuda para entender é: o que devo saber antes de tentar atualizar da v3.4.0 para a v2026.7.2? Nosso site não usa nenhum plugin adicional e a única configuração especial de que tenho conhecimento é que utilizamos uma URL do Discourse Connect para ter SSO com nosso site principal da comunidade.
É tão simples quanto?
cd /var/discourse
git pull
./launcher rebuild app
E, em seguida, atualizar pela interface administrativa? Existem alguma etapa intermediária da qual eu precise estar ciente ao passar da v3.4.0 para a v2026.7.2?
Ou … (considerando que você esteja nervoso) … faça um backup (de qualquer forma) e configure um servidor totalmente novo, restaure o backup e, quando terminar, aponte o domínio para o novo servidor.
Também existe um pequeno risco de que os plugins ou componentes de tema dos quais você depende não tenham sido mantidos, especialmente se forem escritos por terceiros menos ativos.
A ansiedade é a razão pela qual administradores de sistemas experientes do Discourse usam uma configuração com dois contêineres, permitindo que você inicie as atualizações antes de confirmá-las (embora isso não ajude tanto quando há uma grande atualização do Postgres, mas essas atualizações raramente acontecem).
Tentei a migração hoje e, mais uma vez, deparei imediatamente com uma mudança incompatível na branch principal do discourse_docker:
Este commit faz com que os builds falhem e quebra a instalação/configuração, mas foi mesclado na branch principal mesmo assim. Era exatamente isso do que eu estava preocupado.
Ao executar ./launcher bootstrap app, o resultado é:
rake aborted!
Don't know how to build task 'assets:precompile:pretty_text' (See the list of available tasks with `rake --tasks`)
Did you mean? assets:precompile
Como é possível que mudanças incompatíveis como essa estejam sendo mescladas na branch principal, que é fornecida como parte das instruções oficiais de instalação? As falhas nos builds são ignoradas? O mesmo erro que estou vendo está logo ali no log de falha:
Consegui fazer o checkout de um commit anterior, o que me permitiu continuar com as etapas de migração, mas agora estou com 2 para 2 atualizações quebradas por commits não testados mesclados na branch principal.
Obrigado novamente por sugerir essa opção em vez de uma atualização in place. Isso funcionou muito melhor e me permitiu começar com uma cópia limpa de um novo sistema operacional.
