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.

1 me gusta

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, presentamos 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 especificada

Editar templates/web.template.yml

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

Después de realizar este cambio, los pasos para actualizar o mejorar en el futuro consisten en actualizar primero el repositorio de código local. Sin embargo, dado que hemos modificado el código local, es posible que la actualización falle. Por lo tanto, es muy probable que sea necesario almacenar temporalmente los cambios locales con git stash, luego ejecutar git pull para asegurar que el repositorio local esté actualizado. A continuación, modificar la rama que se desea actualizar o especificar, y finalmente reconstruir.

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
1 me gusta

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í.

1 me gusta

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.

4 Me gusta