Ajuda para implantar versões mais antigas do Discourse

Deve haver um erro aqui, tentei buscar por tag v3.6.0.beta2 e obtive o seguinte erro:

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && sudo -H -E -u discourse bash -c '
  set -o errexit
  git fetch --tags --prune-tags --prune --force origin
  if [[ $(git symbolic-ref --short HEAD) == v3.6.0.beta2 ]] ; then
      git pull
  else
      git -c advice.detachedHead=false checkout v3.6.0.beta2
  fi
' failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in `Pups::ExecCommand#spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"code", "cmd'=>["sudo -H -E -u discourse git clean -f", "sudo -H -E -u discourse bash -c '\\n  set -o errexit\\n  git fetch --tags --prune-tags --prune --force origin\\n  if [[ $(git symbolic-ref --short HEAD) == $version ]] ; then\\n      git pull\\n  else\\n      git -c advice.detachedHead=false checkout $version\\n  fi\\n'", "sudo -H -E -u discourse git config user.discourse-version $version", "mkdir -p tmp", "chown discourse:www-data tmp", "mkdir -p tmp/pids", "mkdir -p tmp/sockets", "touch tmp/.gitkeep", "mkdir -p                    /shared/log/rails", "bash -c \"touch -a           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log\"", "bash -c \"ln    -s           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log $home/log\"", "bash -c \"mkdir -p           /shared/{uploads,backups}\"", "bash -c \"ln    -s           /shared/{uploads,backups} $home/public\"", "bash -c \"mkdir -p           /shared/tmp/{backups,restores}\"", "bash -c \"ln    -s           /shared/tmp/{backups,restores} $home/tmp\"", "chown -R discourse:www-data /shared/log/rails /shared/uploads /shared/backups /shared/tmp", "[ ! -d public/plugins ] || find public/plugins/ -maxdepth 1 -xtype l -delete"]}
bootstrap failed with exit code 128
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
adc8ef45e9ae880827c9294dbbf73dfe9ab413a050c83fe3f4722c2911876ce2

version só suporta branches, não tags!

O correto seria

params:
  version: release/2025.11

O motivo pelo qual eu queria buscar por release/2025.11 é que o ambiente de produção atual está em uma versão próxima a esta, e eu queria fazer um upgrade, mas temo que possa haver problemas, e o processo de auditoria não me permite operar o upgrade diretamente. Preciso primeiro validar o processo de upgrade no ambiente de teste (de release/2025.11 para release/2026.1) antes de operar no ambiente de produção. Embora isso seja um pouco tedioso, é a melhor escolha para seguir o processo correto. Assim, fui forçado a procurar uma maneira de buscar um branch ou tag específica aqui.

Desculpe por falar tanto. Felizmente, encontrei uma solução razoável agora. Obrigado a todos.

Continuo a atualizar sobre outros impactos causados por esta modificação:

A instalação de um branch específico foi bem-sucedida, mas a tentativa de fazer o upgrade a partir deste branch falhou. Isso ocorre porque a atualização mais recente não é detectada na página de atualização, impedindo a operação de atualização na página.

1 curtida

Continuando o tópico anterior, um novo problema foi identificado. Quando o repositório local está desatualizado, isso pode causar falhas na compilação do front-end ou outros erros. Portanto, antes de iniciar qualquer modificação, é necessário atualizar o repositório local para a versão mais recente.

# Se você modificou o repositório local anteriormente, faça um stash primeiro
# git stash

# Atualize para a versão mais recente
git pull

# Reaplique o stash ou edite novamente os arquivos de configuração correspondentes
# git stash pop

Somente após atualizar o repositório local para a versão mais recente será possível concluir com sucesso a instalação dos passos anteriores e construir a branch especificada.

O repositório local referido é: https://github.com/discourse/discourse_docker.git

Ou seja, o repositório padrão após a instalação.

Por fim, vamos fazer um resumo.

Nosso objetivo é: instalar uma versão específica.

  1. Atualize o repositório de código local https://github.com/discourse/discourse_docker.git
# Entre no diretório raiz do projeto
cd /var/discourse
# Atualize para a versão mais recente
git pull
  1. Modifique para a versão desejada

Edite o arquivo templates/web.template.yml

params:
  version: release/2026.1
  1. Reconstrua
./launcher rebuild app

Após essa modificação, os passos futuros para atualizar e fazer upgrade serão: primeiro atualizar o repositório de código local. No entanto, como modificamos o código local, a atualização pode falhar. Portanto, é altamente recomendável armazenar temporariamente as alterações locais com git stash, executar git pull para garantir que o repositório local esteja atualizado, modificar o branch de upgrade ou o branch especificado e, finalmente, reconstruir.

Acho que seria muito incomum configurar uma versão específica, em vez de um sabor/stream/tag, como latest ou stable. Na verdade, não tenho mais certeza de quais tags são normais, disponíveis e úteis com este sistema.

Você já deu uma olhada em Configure a supported tracking branch to get Discourse software updates? Talvez ajude a entender quais tags são úteis.

Sim, para usuários comuns, o uso da tag padrão latest é suficiente. No entanto, para o meu cenário específico, é necessário pesquisar como utilizar versões específicas. Não posso dizer ao boss: “Oh, é uma pena, o Discourse não suporta atualmente a verificação de versões específicas; só podemos atualizar para a versão mais recente.”

Este post é muito útil, vou lê-lo com atenção. Obrigado.

Eu não tinha visto isso - obrigado. Parece que devemos usar agora latest/release/esr. Vejo que meu próprio app.yml (antigo) captura o padrão por estar comentado:

  ## Qual revisão do Git este container deve usar? (padrão: tests-passed)
  #version: tests-passed

version atualmente não suporta tags; para suportá-las, é necessário modificar o script de build. A melhor prática seria:

params:
  version: esr

No entanto, atualmente, é necessário alterar para:

params:
  version: release/2026.1
1 curtida

Interessante. Mesmo antes da nova estratégia de versionamento, beta havia sido uma tag em vez de um ramo por bastante tempo: Upcoming changes to the beta branch of Discourse

Sou eu, também estou confuso, mas o código de build atual realmente não suporta tags. Isso não deveria ser assim.

1 curtida

version: release/2026.1 deve funcionar perfeitamente. Se você quiser aproveitar os novos períodos de suporte sobrepostos nas versões, esta é a maneira correta de fazê-lo. (mas, é claro, você deve lembrar de atualizar manualmente antes que a 2026.1 atinja o fim do suporte)

version: esr também deve funcionar. O sistema foi projetado para suportar tags. Ele é implementado como git checkout $version.

Você não deve fazer essa alteração no web.template.yml. Você deve fazê-la no seu arquivo containers/app.yml específico do site.

4 curtidas