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.

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. Atualizar o repositório de código local https://github.com/discourse/discourse_docker.git
# Entrar no diretório raiz do projeto
cd /var/discourse
# Atualizar para a versão mais recente
git pull
  1. Modificar a versão desejada

Edite containers/app.yml e adicione a seguinte configuração no final:

params:
  version: release/2026.1 # A melhor prática seria usar: esr
  1. Reconstruir
./launcher rebuild app

Se for version: esr, não é necessário ler o restante.

Primeiro, execute git pull para garantir que o repositório local esteja atualizado. Em seguida, especifique a branch a ser implantada e, por fim, reconstrua. Esta explicação aplica-se ao cenário de atualização de release/2026.1 para release/2026.7.

Se você apenas deseja atualizar uma instalação já existente de release/2026.1, basta clicar em “Atualizar” no painel de administração. Isso se aplica a cenários em que há atualizações disponíveis para release/2026.1 (especialmente correções de vulnerabilidades).

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

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.

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.

Algo parece não estar certo aqui. Eu estava executando a versão v3.5.0 beta3 com o yml definido como version: tests-passed.

Então, notei essa mudança de versionamento e, antes de reconstruir, alterei o yml para version: esr e depois fiz uma reconstrução via CLI.

Agora, no Discourse, vejo:

Instalado
2026.3.0-latest.1

Isso parece estar usando a tag tests-passed em vez da tag esr. Verifiquei que o app.yml está mostrando a versão como esr, então por que ele está pegando a build mais recente?

Então, essencialmente, não há mais como obter a versão estável / ESR mais recente?

Você pode compartilhar as linhas relevantes do arquivo app.yml? version: está definitivamente indentado abaixo da seção params:? E você definitivamente removeu o caractere de comentário YAML # do início da linha?

Apenas para seu conhecimento, se você quiser voltar para o ESR, precisará restaurar um backup anterior ou aguardar o próximo lançamento do ESR em julho. O downgrade de uma instalação do Discourse não é suportado :cry:

Sim, estou ciente de que não posso fazer downgrade. Anexando uma captura de tela mostrando a indentação.

Notou algo errado aqui?

Acredito que version deve ser indentado porque faz parte de params.

Sim, inicialmente configurei diretamente em containers/app.yml, mas não sei por que não surtiu efeito. Sem outra opção, modifiquei diretamente o arquivo templates/web.template.yml. Vou tentar novamente fazer a modificação em containers/app.yml.

Além disso, você poderia verificar por que a configuração version: esr não está funcionando? É um caso isolado no meu ambiente ou todos enfrentam esse problema? Meu ambiente de rede realmente não é bom.

Configuração abaixo:

params:
  version: v3.6.0.beta2

Erro relatado:

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

A causa raiz é que o comando git symbolic-ref --short HEAD só retorna o nome da branch.