Atascado en v2.9.0.beta1 – ahora ejecutando 3.4.0.beta4-dev después de desactivar Hooks: ¿cómo puedo bloquear las versiones estables?

Soporte
1

Tuve un problema persistente con una instalación de Discourse que estaba atascada en la v2.9.0.beta1; debido a desafíos personales, no pude resolverlo durante años. En ese momento, parecía imposible pasar a la v2.9.0.beta2. Recientemente, mientras solucionaba un problema de reconstrucción, comenté ciertos hooks en mi app.yml (específicamente, los que forzaban un checkout de etiqueta) de la siguiente manera:

hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
    - exec:
        cd: $home
        cmd:
          # - git fetch --depth=1 origin tag v2.9.0.beta2 --no-tags
          # - git checkout v2.9.0.beta2
          - echo "Saltando hook de actualización de versión"

Después de reconstruir, mi instancia se actualizó inesperadamente a la 3.4.0.beta4-dev. Si bien me alegra haber superado ese problema, ahora quiero que el sistema continúe siguiendo el stream beta 3.4.0 hasta que haya una versión estable 3.4.x disponible y, una vez que lo esté, fijarla a esa versión estable para que no se actualice automáticamente a versiones beta o de desarrollo posteriores.

¿Cuál es el método adecuado para “fijar” o bloquear la versión en una versión estable una vez que esté disponible, sin tener que revertir o realizar intervenciones manuales en cada reconstrucción?

¡Cualquier orientación o mejores prácticas sería muy apreciada!

2

Puedes echar un vistazo a esta guía:

3

Cambia tests-passed por stable en tu app.yml. Si no tienes eso en tu yml, puedes consultar el directorio de muestras.

1 me gusta
4

Gracias, así que tenía:

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

Lo actualicé a:

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

Después de la reconstrucción, el sistema está ahora en: 3.5.0.beta1-dev

Lo que parece aún más extraño/peculiar. :thinking:

5

Parece que cambiaste la versión a estable después de la reconstrucción. Ya estás más allá de lo estable, así que tendrás que cambiarla a beta o tests-passed hasta el próximo lanzamiento estable (y como hubo uno en la semana pasada, será dentro de bastante tiempo (típicamente 8-10 meses).

1 me gusta
6

No, desafortunadamente no lo hice… Estoy 100% seguro de esto, estaba en 3.4.0.beta4-dev y luego cambié el app.yml y luego hice la reconstrucción. Entonces apareció 3.5.0.beta1-dev. Este es el camino que se siguió al 100%… No tengo CERO dudas, solo para ser claro al respecto. Literalmente verifiqué las cosas antes de las acciones que he anotado.

7

¿La línea que contiene tests-passed comienza con un #?

8

Captura de pantalla del editor:

Esta imagen muestra un fragmento de script de configuración con detalles sobre la configuración de la base de datos, el repositorio de Git y la memoria, seleccionando específicamente el idioma inglés y utilizando la versión estable en un entorno del sistema. (Subtitulado por IA)
Esta imagen muestra un fragmento de script de configuración con detalles sobre la configuración de la base de datos, el repositorio de Git y la memoria, seleccionando específicamente el idioma inglés y utilizando la versión estable en un entorno del sistema. (Subtitulado por IA)980×395 13.4 KB

9

Está comentado, então o que você colocar lá não importa e o padrão é “testes aprovados”.

Quando você reconstruiu para reconstruir para os últimos “testes aprovados”.

10

Gracias de nuevo por tu ayuda @pfaffman. Para resumir mi comprensión actual:

  • Nuestra instancia estaba ejecutando 3.4.0.beta4-dev, que no se considera una versión estable.
  • Cuando actualicé mi configuración para usar version: stable (con el valor predeterminado comentado), esperaba que las reconstrucciones futuras fijaran la instancia a la rama estable. Sin embargo, dado que ya estábamos en una versión beta, la actualización continuó, lo que resultó en 3.5.0.beta1-dev.
  • Parece que cambiar a version: stable después de haber avanzado más allá de la etiqueta estable no desencadena una reversión; simplemente significa que si estuviéramos en la versión estable o por debajo, nos fijaría a la estable en lugar de seguir las versiones beta.

¿Es eso correcto?

Además, ¿podrías aclarar cuál es el proceso recomendado para asegurarnos de que no sigamos accidentalmente el canal beta en el futuro? Específicamente:

  1. ¿Dejar version: stable como la configuración activa es suficiente para garantizar que, cuando haya una versión estable disponible, nuestras reconstrucciones se fijarán a ella, siempre que no la hayamos superado ya cuando llegue la versión estable?
  2. ¿Existen pasos adicionales o tareas de limpieza (como eliminar o modificar otros elementos de configuración) que debamos realizar para evitar actualizar inadvertidamente a versiones beta/de desarrollo?

Tengo muchas ganas de fijar una versión estable lo antes posible, pero no quiero que vuelva a saltarse esto…

11

Hmm. A mí no me lo parece:

image
image358×114 18.1 KB

12

¡Rayos! Quizás miré demasiado rápido en mi teléfono. No tengo explicación de cómo me perdí eso ni de cómo el sitio ahora está ejecutando 3.5.0.beta1-dev.

2 Me gusta
13

Hola,

Después de sufrir el revés de la actualización 3.4.0.beta4-dev vinculada al cambio de postgres 13 a 15, ¡he podido recuperar una versión funcional 3.5.0.beta1-dev!

Ahora, en el panel, hay una nueva versión:

Instalado             Última
3.5.0.beta1-dev       3.5.0.beta1
(b37b51d15f)

Pero en la página de Actualizaciones, vemos:

Nombre                   Hash de confirmación          Última actualización  Última versión    Estado
¡Nueva versión disponible! v3.4.0.beta4 +182    hace 43 mins   v3.5.0.beta1 +8   Actualizar

¿Es seguro actualizar?

Gracias de antemano.

1 me gusta