Rocket.chat.ansible: Der Relaunch der Website rocket.chat brach den Standardwert von {{rocket_chat_tarball_remote}}

Erstellt am 18. Okt. 2017  ·  24Kommentare  ·  Quelle: RocketChat/Rocket.Chat.Ansible

Hallo Leute,

Der kürzlich erfolgte Relaunch der Website https://rocket.chat hat die Standardeinstellungen dieser Ansible-Rolle zerstört. In ./defaults/main.yml ist das die Variable rocket_chat_tarball_remote , die standardmäßig https://rocket.chat/releases/[github release tag]/download ist.

Diese sind nicht mehr verfügbar und ergeben einen 404.

Darüber hinaus scheint sich die Struktur der Release-Dateien auf Github von denen zu unterscheiden, die bis vor kurzem auf rocket.chat verfügbar waren. Dafür eröffne ich jedoch eine separate Ausgabe unter https://github.com/RocketChat/Rocket.Chat .

Es ist mir auch nicht klar, ob diese Rolle mit den oben erwähnten unterschiedlichen Release-Archiven umgehen kann.

Prost
Thomas

Alle 24 Kommentare

Zu den verschiedenen Release-Archiven: siehe https://github.com/RocketChat/Rocket.Chat/issues/8526

Es stellt sich heraus: Alte Tarballs können immer noch für https://s3.amazonaws.com/download.rocket.chat/build/rocket.chat-[github release tag].tgz abgerufen werden

Werde morgen eine PR machen.

Prost
Thomas

Ich habe meine Ansible-Skripte gepatcht, indem ich den Standardwert auf gesetzt habe:
rocket_chat_tarball_remote: https://cdn-download.rocket.chat/build/rocket.chat-{{ rocket_chat_version }}.tgz

Dies ergibt sich aus dem Download-Link auf der Webseite und wahrscheinlich aus der bevorzugten URL, von der es abgerufen werden soll (nicht direkt über den s3-Bucket, der verschoben werden könnte. @TwizzyDizzy können Sie das bestätigen? Oder in Ihre PR integrieren?

Ja, ich habe diese URL auch herausgefunden, und ich denke, es ist die zu bevorzugende - Sie haben Recht. Ich habe das cdn-download -one in dieser PR verwendet.

Prost
Thomas

@geekgonecrazy Weißt du etwas über diesen CDN-Link? Ich dachte, GH wäre offiziell (und ist das, was auf der Download-Seite aufgeführt ist). Ich bin glücklich, dies zu patchen, ich möchte nur die tatsächliche kanonische Quelle wissen.

Bitte beachten Sie auch: https://github.com/RocketChat/Rocket.Chat/issues/8526

https://cdn-download.rocket.chat/build/rocket.chat-0.59.0.tgz und https://github.com/RocketChat/Rocket.Chat/archive/0.59.0.tar.gz sind NICHT dasselbe.

Ich gehe davon aus (habe es nicht getestet, aber da es im Archiv eine andere Struktur gibt, ist es wahrscheinlich), dass letzteres die Ansible-Rolle brechen würde.

Prost
Thomas

Das macht mir Sorgen.

Behoben von #46, danke @TwizzyDizzy @geekgonecrazy

Entschuldigung für die Verwirrung. Wir haben eine neue Adresse um immer aktuell abholen zu können.

https://github.com/RocketChat/Rocket.Chat/archive/0.59.0.tar.gz ist nur ein Quellcode-Archiv genau so, wie der Code zum Zeitpunkt der Veröffentlichung war. Wobei die von uns gelieferten Archive kompilierte Pakete sind, die bereit sind, npm zu installieren und auszuführen.

Wir evaluieren das Hinzufügen von Bundles zu Github-Releases. Aber vorerst ist die neueste stabile Version verfügbar unter: https://download.rocket.chat/stable und die neueste Kandidatenversion ist verfügbar unter: https://download.rocket.chat/candidate

Edge-Builds werden wahrscheinlich in Zukunft unter https://download.rocket.chat/edge verfügbar sein. Ich arbeite immer noch daran, CI dazu zu bringen.

Nun... was diese Ansible-Rolle betrifft: Sie geht davon aus, dass {{rocket_chat_tarball_remote}} ein Bundle-Build ist (danke für die Terminologie, ich war mir bis jetzt nicht ganz sicher, wie ich das nennen soll).

Ganz ehrlich: Ich finde es sehr wichtig, dass auch „Edge“-Builds (ich nehme an, du meinst „Release Candidates“) gebündelt erscheinen. Sonst wäre ich (zumindest nicht mit dieser Rolle) nicht in der Lage, schnelles Feedback zu Fehlern oder Rückschritten in neuen Release-Kandidaten zu geben. Dass wäre eine Schande.

Prost
Thomas

Ich denke, Edge ist wie ein Nightly, ich denke, "candidate" wäre RC

Ah! Mein Fehler! Ich habe das falsch gelesen. Du hast recht :) Dann ist alles in Ordnung!

Ganz ehrlich: Ich finde es sehr wichtig, dass auch „Edge“-Builds (ich nehme an, du meinst „Release Candidates“) gebündelt erscheinen. Sonst wäre ich (zumindest nicht mit dieser Rolle) nicht in der Lage, schnelles Feedback zu Fehlern oder Rückschritten in neuen Release-Kandidaten zu geben. Dass wäre eine Schande.

Ja, sie werden immer noch als Bundle veröffentlicht 😄 Was wir zur Verfügung stellen, hat sich nicht geändert, wir versuchen nur zu korrigieren, wie wir sie seit der neuen Website präsentieren :)

Es tut mir leid, aber ich glaube, ich muss https://github.com/RocketChat/Rocket.Chat.Ansible/pull/46/commits/c577e6714ff342d6334e51de4093041c31f45585 noch einmal widersprechen ... aber bitte haben Sie Geduld :) . ..

Wenn ich eine bestimmte Version bereitstellen möchte, konnte ich in der Vergangenheit beispielsweise {{rocket_chat_version}} auf eine bestimmte Version wie 0.59.0-rc.13 setzen (auch wenn 0.59.0-rc.17 der neueste Kandidat war). Freisetzung). Mit der aktuellen Version von {{rocket_chat_tarball_remote}} ist dies nicht möglich.

https://download.rocket.chat/rocket.chat-0.59.0-rc.13.tgz führt zu einem 404.

Prost
Thomas

Ja, du hast vollkommen recht. Das Problem ist, dass ich auch keine Ahnung habe, wie ich solche versionierten Builds erreichen kann.

Vielleicht besteht das Ticket darin, dieser Rolle die Funktionalität hinzuzufügen, um von GH zu greifen und sich selbst zu bündeln / zu installieren, wenn eine bestimmte Version benötigt wird?

In Bezug auf die Website selbst - der unglückliche Teil davon, wie @geekgonecrazy erwähnt - gehen die ersten beiden Links "latest stable" und "beta" zu dieser neuen Weiterleitung für stable und candidate , während die Der Link "Vergangene Veröffentlichungen" führt Sie nur zu GH, wo es keine Bundles gibt :(

Exakt. Meine Problemumgehung mit https://cdn-download.rocket.chat/build/rocket.chat-{{ rocket_chat_version }}.tgz funktioniert immer noch, aber ich weiß nicht, ob das von Dauer sein wird.

Aber das wäre ein großer Nachteil. Der Vorteil von gebündelten Releases ist, dass Sie es nicht selbst erstellen müssen (und dadurch keine Build-ENV in Ihrer PROD-Umgebung haben müssen und die Bereitstellung selbst nicht lange dauert).

Prost
Thomas

Ja, da bin ich ganz bei dir. Ich hoffe, @geekgonecrazy kann klarstellen, was die offizielle Empfehlung hier ist, weil ich auch nicht weiß, ob dieser CDN-Link Bestand haben wird.

Wo ich denke, dass dies wahrscheinlich enden wird ... Sie werden wahrscheinlich irgendwann Bundles für GH anbieten, und dort werden wir die spezifischen Builds bekommen

Mal sehen, was er zu sagen hat :) Bundles on github... yeah - wäre wahrscheinlich die richtige Wahl.

Was die Meinungsverschiedenheit mit dem Commit betrifft. Ich bin mir nicht sicher, ob ich verstehe, warum es Meinungsverschiedenheiten gibt. Es ist ein Drop-in-Ersatz, der genau das tut, was er zuvor getan hat.

Bezüglich spezifischer Versionen sind sie verfügbar unter: https://download.rocket.chat/build/rocket.chat-0.59.1.tgz
Die .asc-Datei ist verfügbar unter: https://download.rocket.chat/build/rocket.chat-0.59.1.tgz.asc

Natürlich nur die Versionsnummer für die spezifische Version austauschen

Ich habe diesen Commit bereits zusammengeführt (mit einigen meiner eigenen Änderungen). Keine Meinungsverschiedenheiten. Wir haben gerade die Tatsache besprochen, dass ein Benutzer früher in der Lage war, die Version zu sperren, indem er (jetzt) ​​"stable" durch eine Versionsnummer ersetzte.

Jetzt muss ich in die Logik schreiben, um festzustellen, ob eine Versionssperre erwünscht ist, und dann den neuen Pfad von https://download.rocket.chat/build/rocket.chat-{version}.tgz , was keine große Sache ist, aber ich denke, das war es, womit er "nicht einverstanden" war.

Schön @ the asc, ich wusste nicht, dass Sie diese bereitstellen. Das sind großartige Neuigkeiten, denn es bedeutet, dass ich den SHA256-Test (und mich selbst als manuellen Schiedsrichter für den „wahren Hash“) fallen lassen und einfach GPG verwenden kann, um die Tarballs zu überprüfen. Ich liebe es, weil ich diesen Prozess endlich automatisieren und die manuelle Aktualisierung loswerden kann.

Jetzt muss ich in die Logik schreiben, um zu erkennen, ob eine Versionssperre erwünscht ist, und dann auf den neuen Pfad von https://download.rocket.chat/build/rocket.chat-{version}.tgz klicken, der nein ist große Sache, aber ich denke, damit war er "nicht einverstanden".

Okay, das macht Sinn. Das ist auch meine persönliche Präferenz. In der Produktion verlinke ich nie auf "neueste" oder "stabile", ich tagge immer eine Version.

Zum Glück sehe ich keinen Grund, das noch einmal zu ändern. Anstatt sich jetzt auf unsere Website-"App" zu verlassen, um die Weiterleitung durchzuführen. Links sind direkt zu den Dateien, was helfen sollte.

Schön @ the asc, ich wusste nicht, dass Sie diese bereitstellen. Das sind großartige Neuigkeiten, denn es bedeutet, dass ich den SHA256-Test (und mich selbst als manuellen Schiedsrichter für den „wahren Hash“) fallen lassen und einfach GPG verwenden kann, um die Tarballs zu überprüfen. Ich liebe es, weil ich diesen Prozess endlich automatisieren und die manuelle Aktualisierung loswerden kann.

Ja, wir haben damit begonnen und verwenden es tatsächlich nur in unserem Docker-Image-Build. Habe es aber sonst nirgends genutzt. Ich kann mir vorstellen, dass das Aktualisieren jedes Mal ziemlich nervig ist.

Lassen Sie mich wissen, wenn ich irgendetwas tun kann, um zu helfen 👍

Informieren Sie sich über dieses Problem, wenn Sie auf get_url Probleme stoßen: https://github.com/ansible/ansible/issues/31998

Cloudfront benötigt SNI-Unterstützung und diese ist derzeit defekt, wenn urllib3 installiert ist

Der Fehler hier wurde behoben, um ihn in https://github.com/RocketChat/Rocket.Chat.Ansible/releases/tag/v2.2.5 zu meistern

Schließen wir dies zugunsten von zwei verzweigten Themen, die angesprochen wurden. #50 und #52

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen