Ayuda para desplegar versiones antiguas de Discourse

Aquí debería haber un error, intenté extraer v3.6.0.beta2 a través de una etiqueta y obtuve el siguiente error:

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 '
  set -o errexit
  git fetch --tags --prune-tags --prune --force origin
  if [[ $(git symbolic-ref --short HEAD) == $version ]] ; then
      git pull
  else
      git -c advice.detachedHead=false checkout $version
  fi
'", "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,/shared/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 solo admite ramas, no admite etiquetas!

Lo correcto debería ser

params:
  version: release/2025.11

En cuanto a por qué quiero extraer release/2025.11, es porque la versión en producción es una versión cercana a esta, y quiero actualizar, pero me preocupa que surjan problemas. Además, el proceso de revisión no me permite operar la actualización directamente, sino que debo validar primero el proceso de actualización en el entorno de prueba (release/2025.11=>release/2026.1) y solo entonces puedo operar en el entorno de producción. Aunque esto es un poco tedioso, es la mejor opción para un proceso correcto. Por lo tanto, tuve que buscar aquí la forma de extraer una rama o etiqueta específica.

Disculpen por toda esta palabrería. Afortunadamente, ahora he encontrado una solución bastante aceptable. Gracias a todos.

Continué actualizando otros efectos causados por esta modificación:

La instalación de la rama específica se implementó, pero la verificación de la actualización desde esta rama falló. Esto se debe a que la actualización más reciente no se detecta en la página de actualización, lo que impide realizar la actualización desde la página.

Continuando con el tema anterior, se ha detectado un nuevo problema. Cuando el repositorio local está desactualizado, provoca fallos en la compilación del frontend u otros errores. Por lo tanto, antes de realizar cualquier modificación, es necesario actualizar el repositorio local a la versión más reciente.

# Si se han realizado modificaciones en el repositorio local, guárdalas primero
# git stash

# Actualizar a la última versión
git pull

# Volver a aplicar las modificaciones guardadas, o editar nuevamente los archivos de configuración correspondientes
# git stash pop

Solo después de actualizar el repositorio local a la versión más reciente, la instalación podrá completarse con éxito según los pasos anteriores para construir la rama especificada.

El repositorio local al que se hace referencia es: https://github.com/discourse/discourse_docker.git

Es decir, el repositorio estándar tras la instalación.

Finalmente, un resumen.

Nuestro requisito es: instalar una versión específica.

  1. Actualizar el repositorio de código local https://github.com/discourse/discourse_docker.git
# Entrar al directorio raíz del proyecto
cd /var/discourse
# Actualizar a la última versión
git pull
  1. Modificar la versión específica a instalar

Editar containers/app.yml y agregar la siguiente configuración al final:

params:
  version: release/2026.1 # La mejor práctica es escribir: esr
  1. Reconstruir nuevamente
./launcher rebuild app

Si usas version: esr, no necesitas leer lo siguiente.

Primero, ejecuta git pull para asegurar que el repositorio local esté actualizado. Luego, especifica la rama que deseas desplegar y finalmente reconstruye. Esta explicación es útil para escenarios donde se desea actualizar desde release/2026.1 hacia release/2026.7.

Si solo deseas actualizar una instalación existente de release/2026.1, simplemente haz clic en “Actualizar” en el panel de administración. Esto es aplicable cuando hay actualizaciones disponibles para release/2026.1 (especialmente correcciones de vulnerabilidades).

Creo que sería muy inusual configurar una versión específica, en lugar de un sabor/flujo/etiqueta, como latest o stable. En realidad, ya no estoy seguro de qué etiquetas son normales, disponibles y útiles con este sistema.

¿Has echado un vistazo a Configure a supported tracking branch to get Discourse software updates? Quizás te ayude a entender qué etiquetas son útiles.

Sí, para los usuarios normales, usar la versión predeterminada latest es suficiente. Sin embargo, para mi caso, es necesario investigar cómo utilizar una versión específica. No puedo decirle a boss: “Oh, lo siento, Discourse no admite actualmente la verificación de versiones específicas; solo podemos actualizar a la última versión”.

Este post es muy útil, lo revisaré detenidamente. Gracias.

No había visto eso, gracias. Parece que deberíamos estar usando ahora latest/release/esr. Veo que mi propio archivo app.yml (antiguo) adopta el valor predeterminado al estar comentado:

  ## ¿Qué revisión de Git debe usar este contenedor? (predeterminado: tests-passed)
  #version: tests-passed

version actualmente no admite etiquetas; para habilitarlas, es necesario modificar el script de construcción. La mejor práctica sería:

params:
  version: esr

Sin embargo, actualmente es necesario modificarlo a:

params:
  version: release/2026.1

Interesante. Incluso antes de la nueva estrategia de versionamiento, beta había sido una etiqueta en lugar de una rama durante bastante tiempo: Upcoming changes to the beta branch of Discourse

Soy yo, también estoy confundido, pero el código de compilación actual realmente no puede usar etiquetas. Esto no debería ser así.

version: release/2026.1 debería funcionar sin problemas. Si deseas aprovechar los nuevos períodos de soporte superpuestos en las versiones, esta es la forma correcta de hacerlo (pero, por supuesto, debes recordar actualizar manualmente antes de que 2026.1 alcance su fin de vida).

version: esr también debería funcionar. El sistema está diseñado para admitir etiquetas. Se implementa como git checkout $version.

No debes realizar este cambio en web.template.yml. Debes hacerlo en tu archivo containers/app.yml específico del sitio.

Algo no parece estar bien aquí. Estaba ejecutando v3.5.0 beta3 con el archivo yml configurado como version: tests-passed.

Luego noté este cambio en la versión, así que antes de reconstruir, cambié el yml a version: esr y luego realicé una reconstrucción desde la CLI.

Ahora en Discourse veo:

Instalado
2026.3.0-latest.1

Esto parece estar utilizando la etiqueta tests-passed en lugar de la etiqueta esr. Verifiqué que app.yml muestra la versión como esr, ¿por qué está tomando la compilación más reciente?

¿Entonces, en esencia, ya no hay forma de obtener la versión estable / ESR más reciente?

¿Podrías compartir las líneas relevantes del archivo app.yml? ¿Está version: definitivamente indentado bajo la sección params:? ¿Y has eliminado definitivamente el carácter de comentario YAML # del principio de la línea?

Solo por si acaso, si deseas volver a ESR, necesitarás restaurar una copia de seguridad anterior o esperar hasta la próxima versión ESR en julio. La desinstalación de una instalación de Discourse no es compatible :cry:

Sí, soy consciente de que no puedo revertir la versión. Adjunto una captura de pantalla que muestra la sangría.

¿Notas algo incorrecto aquí?

Creo que version debería estar indentado porque es parte de params.

Sí, al principio lo configuré directamente en containers/app.yml, pero no sé por qué no surtió efecto, así que, sin otra opción, modifiqué directamente templates/web.template.yml. Intentaré nuevamente hacer la modificación en containers/app.yml.

Además, ¿podrías revisar por qué la configuración version: esr no tiene efecto? ¿Es un caso aislado en mi entorno o le ocurre a todos? Mi entorno de red es realmente deficiente.

La configuración es la siguiente:

params:
  version: v3.6.0.beta2

El error reportado es:

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

La causa raíz es que el comando git symbolic-ref --short HEAD solo puede devolver el nombre de la rama.