Rocket.chat.ansible: La relance du site Web rocket.chat a cassé la valeur par défaut de {{rocket_chat_tarball_remote}}

Concernant les différentes archives de release : voir https://github.com/RocketChat/Rocket.Chat/issues/8526

Il s'avère que les archives tar à l'ancienne peuvent toujours être récupérées à https://s3.amazonaws.com/download.rocket.chat/build/rocket.chat-[github release tag].tgz

Je vais faire un PR demain.

Acclamations
Thomas

J'ai corrigé mes scripts ansibles en définissant la valeur par défaut sur :
rocket_chat_tarball_remote: https://cdn-download.rocket.chat/build/rocket.chat-{{ rocket_chat_version }}.tgz

Ceci est déduit par le lien de téléchargement sur la page Web et probablement l'URL préférée pour le récupérer (pas directement via le compartiment s3 qui pourrait être déplacé. @TwizzyDizzy pouvez-vous le confirmer ? Ou l'intégrer dans votre PR ?

Oui, j'ai découvert cette URL aussi, et je pense que c'est celle à préférer - vous avez raison. J'ai utilisé le cdn-download -one dans ce PR.

Acclamations
Thomas

@geekgonecrazy Savez-vous quelque chose sur ce lien CDN ? Je pensais que GH était officiel (et c'est ce qui est indiqué sur la page de téléchargement). Je suis heureux de corriger cela, je veux juste connaître la source canonique réelle.

Veuillez également garder à l'esprit : https://github.com/RocketChat/Rocket.Chat/issues/8526

https://cdn-download.rocket.chat/build/rocket.chat-0.59.0.tgz et https://github.com/RocketChat/Rocket.Chat/archive/0.59.0.tar.gz ne sont PAS les mêmes.

Je suppose (je n'ai pas testé, mais comme il y a une structure différente dans l'archive, il est probable) que ce dernier casserait le rôle ansible.

Acclamations
Thomas

C'est ce qui m'inquiète.

Corrigé par #46, merci @TwizzyDizzy @geekgonecrazy

Désolé pour la confusion. Nous avons une nouvelle adresse pour pouvoir toujours récupérer la dernière.

https://github.com/RocketChat/Rocket.Chat/archive/0.59.0.tar.gz est juste une archive de code source exactement comme le code est au moment de la publication. Alors que les archives que nous expédions sont des bundles compilés prêts pour l'installation et l'exécution de npm.

Nous évaluons l'ajout de bundles aux versions de github. Mais pour l'instant, la dernière version stable est disponible sur : https://download.rocket.chat/stable et la dernière version candidate est disponible sur : https://download.rocket.chat/candidate

les versions edge seront probablement disponibles à l'avenir sur https://download.rocket.chat/edge . Toujours en train de travailler pour que CI soit connecté pour le faire.

Eh bien... en ce qui concerne ce rôle ansible : il suppose que {{rocket_chat_tarball_remote}} est une construction groupée (merci pour la terminologie, je ne savais pas trop comment l'appeler jusqu'à présent).

Pour être honnête: je trouve très important que les versions "edge" (je suppose que vous voulez dire "release candidates") soient également publiées en bundle. Sinon, je ne serais pas en mesure (du moins pas avec ce rôle) de fournir un retour rapide sur les bogues ou les régressions dans les nouvelles versions candidates. Ce serait une honte.

Acclamations
Thomas

Je pense que le bord est comme un soir, je pense que "candidat" serait RC

Ah ! Ma faute! J'ai mal lu ça.. tu as raison :) Alors tout va bien !

Pour être honnête: je trouve très important que les versions "edge" (je suppose que vous voulez dire "release candidates") soient également publiées en bundle. Sinon, je ne serais pas en mesure (du moins pas avec ce rôle) de fournir un retour rapide sur les bogues ou les régressions dans les nouvelles versions candidates. Ce serait une honte.

oui, ils sont toujours publiés sous forme groupée 😄 Ce que nous mettons à disposition n'a pas changé, nous essayons simplement de corriger la façon dont nous les présentons depuis le nouveau site Web :)

Je suis désolé, mais je pense que je dois m'opposer une fois de plus à https://github.com/RocketChat/Rocket.Chat.Ansible/pull/46/commits/c577e6714ff342d6334e51de4093041c31f45585 ... mais s'il vous plaît, supportez-moi :) . ..

Si je veux déployer une version spécifique, dans le passé, je pouvais, par exemple, définir {{rocket_chat_version}} sur une version spécifique comme 0.59.0-rc.13 (même si 0.59.0-rc.17 était le dernier candidat Libération). Avec la version actuelle de {{rocket_chat_tarball_remote}} , ce n'est pas possible.

https://download.rocket.chat/rocket.chat-0.59.0-rc.13.tgz mène à un 404.

Acclamations
Thomas

Ouais, tu as tout à fait raison. Le problème est que je ne sais pas non plus comment atteindre des versions versionnées comme celle-ci.

Peut-être que le ticket consiste à ajouter la fonctionnalité à ce rôle afin de récupérer de GH et de se regrouper/s'installer lorsqu'une version spécifique est nécessaire ?

En ce qui concerne le site lui-même - la partie malheureuse de cela, comme @geekgonecrazy l'a mentionné - les deux premiers liens "dernier stable" et "bêta" vont vers cette nouvelle redirection pour stable et candidate , alors que le Le lien "Past releases" vous amène simplement à GH où il n'y a pas de bundles :(

Exactement. Ma solution de contournement avec https://cdn-download.rocket.chat/build/rocket.chat-{{ rocket_chat_version }}.tgz fonctionne toujours, mais je ne sais pas si cela va durer.

Mais ce serait un inconvénient majeur. L'avantage d'avoir des versions groupées est que vous n'avez pas besoin de le construire vous-même (et donc vous n'avez pas besoin d'avoir une construction ENV sur votre environnement PROD et le déploiement lui-même ne prend pas longtemps).

Acclamations
Thomas

Ouais, je suis complètement d'accord avec toi. J'espère que @geekgonecrazy pourra clarifier la recommandation officielle ici, car je ne sais pas non plus si ce lien CDN durera.

Où je pense que cela finira probablement... Ils finiront probablement par fournir des bundles sur GH à un moment donné et c'est là que nous obtiendrons les versions spécifiques

Voyons voir, était-il obligé de dire :) Bundles sur github... ouais - serait probablement le bon choix.

Quant au désaccord avec le commit. Je ne suis pas sûr de comprendre pourquoi il y a désaccord. C'est une baisse de remplacement qui fait exactement ce qu'elle faisait auparavant.

Quant aux versions spécifiques, elles sont disponibles sur : https://download.rocket.chat/build/rocket.chat-0.59.1.tgz
Le .asc est disponible sur : https://download.rocket.chat/build/rocket.chat-0.59.1.tgz.asc

Bien sûr, il suffit d'échanger le numéro de version pour la version spécifique

J'ai déjà fusionné ce commit (avec certains de mes propres changements). Pas de désaccord. Nous discutions juste du fait qu'auparavant un utilisateur pouvait verrouiller une version en remplaçant (maintenant) "stable" par un numéro de version.

Maintenant, je vais devoir écrire dans la logique pour détecter si un verrou de version est souhaité, puis appuyer sur le nouveau chemin de https://download.rocket.chat/build/rocket.chat-{version}.tgz , ce qui n'est pas grave mais je pense que c'est ce avec quoi il "n'était pas d'accord".

Nice @ the asc cependant, je ne savais pas que vous les fournissiez. C'est une excellente nouvelle car cela signifie que je peux abandonner le test SHA256 (et moi-même en tant qu'arbitre manuel de ce qu'est le "vrai hachage") et simplement utiliser GPG pour vérifier les archives. J'adore, car je peux enfin automatiser ce processus et me débarrasser de la mise à jour manuelle.

Maintenant, je vais devoir écrire dans la logique pour détecter si un verrou de version est souhaité, puis cliquer sur le nouveau chemin de https://download.rocket.chat/build/rocket.chat-{version}.tgz , qui n'est pas gros problème, mais je pense que c'est ce avec quoi il était "en désaccord".

Ok, oui c'est logique. C'est aussi personnellement ma préférence. En production, je ne mets jamais de lien vers "dernière" ou "stable", je tague toujours une version.

Heureusement, je ne vois aucune raison pour que cela change à nouveau. Maintenant, au lieu de compter sur notre "application" de site Web pour effectuer la redirection. Les liens sont directement vers les fichiers, ce qui devrait aider.

Nice @ the asc cependant, je ne savais pas que vous les fournissiez. C'est une excellente nouvelle car cela signifie que je peux abandonner le test SHA256 (et moi-même en tant qu'arbitre manuel de ce qu'est le "vrai hachage") et simplement utiliser GPG pour vérifier les archives. J'adore, car je peux enfin automatiser ce processus et me débarrasser de la mise à jour manuelle.

Oui, nous avons commencé à le faire et nous ne l'utilisons que dans notre construction d'image Docker. Mais ne l'avait utilisé nulle part ailleurs. Je peux imaginer que la mise à jour à chaque fois est assez ennuyeuse.

Faites-moi savoir si je peux faire quelque chose pour vous aider 👍

Attention à ce problème si vous rencontrez des problèmes get_url : https://github.com/ansible/ansible/issues/31998

Cloudfront nécessite la prise en charge de SNI et celle-ci est actuellement interrompue si urllib3 est installé

Le bogue ici a été corrigé pour maîtriser dans https://github.com/RocketChat/Rocket.Chat.Ansible/releases/tag/v2.2.5

Clôturant ceci en faveur de deux questions ramifiées qui ont été soulevées. #50 et #52