Rocket.chat.ansible: El relanzamiento del sitio web de cohete.chat rompió el valor predeterminado de {{rocket_chat_tarball_remote}}

Con respecto a los diferentes archivos de lanzamiento: consulte https://github.com/RocketChat/Rocket.Chat/issues/8526

Resulta que los tarballs de estilo antiguo todavía se pueden obtener a https://s3.amazonaws.com/download.rocket.chat/build/rocket.chat-[github release tag].tgz

Voy a hacer una PR mañana.

Salud
Tomás

Parcheé mis scripts de ansible estableciendo el valor predeterminado en:
rocket_chat_tarball_remote: https://cdn-download.rocket.chat/build/rocket.chat-{{ rocket_chat_version }}.tgz

Esto se deduce del enlace de descarga en la página web y probablemente la URL preferida para obtenerlo (no directamente a través del depósito s3 que podría moverse. @TwizzyDizzy , ¿puede confirmar esto? o integrarlo en su PR?

Sí, también descubrí esta URL y creo que es la preferida. Tienes razón. Usé el cdn-download -uno en este PR.

Salud
Tomás

@geekgonecrazy ¿Sabes algo sobre este enlace CDN? Pensé que GH era oficial (y es lo que aparece en la página de descarga). Estoy feliz de parchear esto, solo quiero saber la fuente canónica real.

También tenga en cuenta: https://github.com/RocketChat/Rocket.Chat/issues/8526

https://cdn-download.rocket.chat/build/rocket.chat-0.59.0.tgz y https://github.com/RocketChat/Rocket.Chat/archive/0.59.0.tar.gz NO son lo mismo.

Supongo (no lo he probado, pero como hay una estructura diferente en el archivo es probable) que este último rompería el rol ansible.

Salud
Tomás

Eso es lo que me preocupa.

Solucionado por #46, gracias @TwizzyDizzy @geekgonecrazy

Perdón por la confusión. Tenemos una nueva dirección para poder buscar siempre lo último.

https://github.com/RocketChat/Rocket.Chat/archive/0.59.0.tar.gz es solo un archivo de código fuente exactamente como el código en el momento del lanzamiento. Mientras que los archivos que enviamos son paquetes compilados listos para instalar y ejecutar npm.

Estamos evaluando agregar paquetes a las versiones de github. Pero por ahora, la versión estable más reciente está disponible en: https://download.rocket.chat/stable y la versión candidata más reciente está disponible en: https://download.rocket.chat/candidate

Es probable que las compilaciones de borde estén disponibles en el futuro en https://download.rocket.chat/edge . Todavía estoy trabajando para conectar a CI para hacer esto.

Bueno... en cuanto a este rol ansible: asume que {{rocket_chat_tarball_remote}} es una compilación de paquete (gracias por la terminología, no estaba muy seguro de cómo llamarlo hasta ahora).

Para ser honesto: me parece muy importante que también se publiquen compilaciones de "borde" (supongo que te refieres a "candidatos de lanzamiento"). De lo contrario, no podría (al menos no con este rol) proporcionar comentarios rápidos sobre errores o regresiones en nuevos candidatos de versión. Eso sería una verguenza.

Salud
Tomás

Creo que edge es como un nightly, creo que el "candidato" sería RC

¡Ay! ¡Mi error! Leí mal esto... tienes razón :) ¡Entonces todo está bien!

Para ser honesto: me parece muy importante que también se publiquen compilaciones de "borde" (supongo que te refieres a "candidatos de lanzamiento"). De lo contrario, no podría (al menos no con este rol) proporcionar comentarios rápidos sobre errores o regresiones en nuevos candidatos de versión. Eso sería una verguenza.

sí, todavía se lanzan como paquetes 😄 Lo que ponemos a disposición no ha cambiado, solo intentamos arreglar cómo los presentamos desde el nuevo sitio web :)

Lo siento, pero creo que tengo que objetar una vez más a https://github.com/RocketChat/Rocket.Chat.Ansible/pull/46/commits/c577e6714ff342d6334e51de4093041c31f45585... pero, por favor, tengan paciencia conmigo :). ..

Si quiero implementar una versión específica, en el pasado podía, por ejemplo, establecer {{rocket_chat_version}} en una versión específica como 0.59.0-rc.13 (incluso si 0.59.0-rc.17 era el último candidato liberar). Con la versión actual de {{rocket_chat_tarball_remote}} esto no es posible.

https://download.rocket.chat/rocket.chat-0.59.0-rc.13.tgz conduce a un 404.

Salud
Tomás

Sí, tienes toda la razón. El problema es que tampoco tengo idea de cómo llegar a compilaciones versionadas como esta.

¿Quizás el boleto es agregar la funcionalidad a este rol para tomar de GH y empaquetar/instalar cuando se necesite una versión específica?

Con respecto al sitio en sí, la parte desafortunada de esto, como mencionó @geekgonecrazy , los dos primeros enlaces "último estable" y "beta" van a esta nueva redirección para stable y candidate , mientras que el El enlace "Lanzamientos anteriores" solo lo lleva a GH donde no hay paquetes :(

Exactamente. Mi solución alternativa con https://cdn-download.rocket.chat/build/rocket.chat-{{ rocket_chat_version }}.tgz todavía funciona, pero no sé si va a durar.

Pero esto sería un gran inconveniente. La ventaja de tener versiones agrupadas es que no necesita compilarlo usted mismo (y, por lo tanto, no necesita tener un ENV de compilación en su entorno PROD y la implementación en sí no lleva mucho tiempo).

Salud
Tomás

Sí, estoy contigo allí completamente. Espero que @geekgonecrazy pueda aclarar cuál es la recomendación oficial aquí porque tampoco sé si ese enlace CDN durará.

Donde creo que esto probablemente terminará... Probablemente terminarán proporcionando paquetes en GH en algún momento y ahí es donde obtendremos las compilaciones específicas.

Veamos, ¿tenía que decirlo? :) Paquetes en github... sí, probablemente sería la elección correcta.

En cuanto al desacuerdo con el compromiso. No estoy seguro de entender por qué hay desacuerdo. Es un reemplazo directo que hace exactamente lo que hacía anteriormente.

Las versiones específicas están disponibles en: https://download.rocket.chat/build/rocket.chat-0.59.1.tgz
El .asc está disponible en: https://download.rocket.chat/build/rocket.chat-0.59.1.tgz.asc

Por supuesto, simplemente cambiando el número de versión por la versión específica

Ya fusioné ese compromiso (con algunos de mis propios cambios). Sin desacuerdo. Estábamos discutiendo el hecho de que anteriormente un usuario podía bloquear la versión reemplazando (ahora) "estable" con un número de versión.

Ahora, tendré que escribir en la lógica para detectar si se desea un bloqueo de versión, luego presionar la nueva ruta de https://download.rocket.chat/build/rocket.chat-{version}.tgz , que no es gran cosa, pero creo que eso es con lo que él estaba "en desacuerdo".

Sin embargo, Nice @ the asc, no sabía que los estaba proporcionando. Esa es una gran noticia porque significa que puedo descartar la prueba SHA256 (y a mí mismo como árbitro manual de lo que es el "verdadero hash") y simplemente usar GPG para verificar los tarballs. Me encanta, porque finalmente puedo automatizar ese proceso y deshacerme de la actualización manual.

Ahora, tendré que escribir la lógica para detectar si se desea un bloqueo de versión, luego presionar la nueva ruta de https://download.rocket.chat/build/rocket.chat- {version}.tgz, que no es gran cosa, pero creo que eso es con lo que estaba "en desacuerdo".

Vale, sí, eso tiene sentido. Esta es personalmente mi preferencia también. En producción, nunca enlazo a "más reciente" o "estable", siempre etiqueto una versión.

Afortunadamente no veo ninguna razón para que cambie de nuevo. Ahora, en lugar de confiar en la "aplicación" de nuestro sitio web para realizar la redirección. Los enlaces son directamente a los archivos, lo que debería ayudar.

Sin embargo, Nice @ the asc, no sabía que los estaba proporcionando. Esa es una gran noticia porque significa que puedo descartar la prueba SHA256 (y a mí mismo como árbitro manual de lo que es el "verdadero hash") y simplemente usar GPG para verificar los tarballs. Me encanta, porque finalmente puedo automatizar ese proceso y deshacerme de la actualización manual.

Sí, comenzamos a hacer eso y, de hecho, lo usamos solo en nuestra compilación de imagen de ventana acoplable. Pero no lo había utilizado en ningún otro lugar. Me imagino que actualizar cada vez es bastante molesto.

Avísame si hay algo que pueda hacer para ayudar 👍

Preste atención a este problema si se encuentra con problemas get_url : https://github.com/ansible/ansible/issues/31998

Cloudfront requiere compatibilidad con SNI y actualmente no funciona si urllib3 está instalado

El error aquí se ha corregido para dominar en https://github.com/RocketChat/Rocket.Chat.Ansible/releases/tag/v2.2.5

Cerrando esto a favor de dos cuestiones bifurcadas que se plantearon. #50 y #52