Rocket.chat.ansible: Relaunch of rocket.chat website broke default of {{rocket_chat_tarball_remote}}

Concerning the different release archives: see https://github.com/RocketChat/Rocket.Chat/issues/8526

Turns out: old-style tarballs can still be fetched at https://s3.amazonaws.com/download.rocket.chat/build/rocket.chat-[github release tag].tgz

Gonna do a PR tomorrow.

Cheers
Thomas

I Patched my ansible scripts by setting the defaults value to:
rocket_chat_tarball_remote: https://cdn-download.rocket.chat/build/rocket.chat-{{ rocket_chat_version }}.tgz

This is deduced by teh download link on the webpage and likely the prefered URL to fetch it from (not direct through the s3 bucket which could be moved. @TwizzyDizzy can you confirm this? or integrate it into your PR?

Yes, I found out this URL, too, and I think it is the one to prefer - you are right. I used the cdn-download-one in this PR.

Cheers
Thomas

@geekgonecrazy Do you know anything about this CDN link? I thought GH was official (and is what's listed on the download page). I'm happy to patch this I just want to know the actual canonical source.

Please also keep in mind: https://github.com/RocketChat/Rocket.Chat/issues/8526

https://cdn-download.rocket.chat/build/rocket.chat-0.59.0.tgz and https://github.com/RocketChat/Rocket.Chat/archive/0.59.0.tar.gz are NOT the same.

I assume (haven't tested, but as there's a different structure in the archive it is likely) that the latter would break the ansible role.

Cheers
Thomas

That's what worries me.

Fixed by #46, thanks @TwizzyDizzy @geekgonecrazy

Sorry about the confusion. We have a new address to be able to always fetch latest.

https://github.com/RocketChat/Rocket.Chat/archive/0.59.0.tar.gz is just a source code archive exactly as the code is at the time of the release. Where as the archives we ship are compiled bundles ready for doing npm install and running.

We are evaluating adding bundles to github releases. But for now latest stable is available at: https://download.rocket.chat/stable and latest candidate release is available at: https://download.rocket.chat/candidate

edge builds will likely in the future be available at https://download.rocket.chat/edge . Still working on getting CI all hooked up to do this.

Well... as for this ansible role: it assumes that {{rocket_chat_tarball_remote}} is a bundle build (thanks for the terminology, I wasn't quite sure how to call this up until now).

To be honest: I find it very important that also "edge" builds (I assume you mean "release candidates") are released bundled. Otherwise I would not (at least not with this role) be able to provide fast feedback on bugs or regressions in new release candidates. That would be a shame.

Cheers
Thomas

I think edge is like a nightly, I think "candidate" would be RC

Ah! My bad! I misread this.. you're right :) Then everything is fine!

To be honest: I find it very important that also "edge" builds (I assume you mean "release candidates") are released bundled. Otherwise I would not (at least not with this role) be able to provide fast feedback on bugs or regressions in new release candidates. That would be a shame.

yes they are still released as bundled 😄 What we make available hasn't changed, just trying to fix how we present them since the new website :)

I'm sorry, but I think I have to object once again to https://github.com/RocketChat/Rocket.Chat.Ansible/pull/46/commits/c577e6714ff342d6334e51de4093041c31f45585 ... but please, bear with me :) ...

If I want to deploy a specific version, in the past I could, for example, set {{rocket_chat_version}} to a specific version like 0.59.0-rc.13 (even if 0.59.0-rc.17 was the latest candidate release). With the current version of {{rocket_chat_tarball_remote}} this is not possible.

https://download.rocket.chat/rocket.chat-0.59.0-rc.13.tgz leads to a 404.

Cheers
Thomas

Yeah, you're completely right. Problem is I have no idea how to reach versioned builds like this, either.

Perhaps the ticket is to add the functionality to this role in order to grab from GH and bundle/install itself when a specific version is needed?

Regarding the site itself - the unfortunate part of this, like @geekgonecrazy mentioned - the first two links "latest stable" and "beta" go to this new redirect for stable and candidate, whereas the "Past releases" link just takes you to GH where there are no bundles :(

Exactly. My workaround with https://cdn-download.rocket.chat/build/rocket.chat-{{ rocket_chat_version }}.tgz still works, but I don't know if that's gonna last.

But this would be a major drawback. The advantage of having bundled releases is, that you don't need to build it yourself (and thereby don't have to have a build ENV on your PROD environment and the deployment itself doesn't take long).

Cheers
Thomas

Yeah, I'm with you there completely. I hope @geekgonecrazy can clarify what the official recommendation is here because I don't know if that CDN link will last, either.

Where I think this is probably going to end up... They're probably going to end up providing bundles on GH at some point and that's where we'll get the specific builds

Let's see, was he has to say :) Bundles on github... yeah - would probably be the right choice.

As to the disagreement with the commit. I'm not sure I understand why there is disagreement. It's a drop in replacement that does exactly what it previously did.

As to specific versions they are available at: https://download.rocket.chat/build/rocket.chat-0.59.1.tgz
The .asc is available at: https://download.rocket.chat/build/rocket.chat-0.59.1.tgz.asc

Of course just swapping out the version number for the specific version

I already merged that commit (with some of my own changes). No disagreement. We were just discussing the fact that previously a user was able to version lock by replacing (now) "stable" with a version number.

Now, I will have to write in the logic to detect if a version lock is wanted, then hit the new path of https://download.rocket.chat/build/rocket.chat-{version}.tgz, which is no big deal but I think that's what he was "disagreeing" with.

Nice @ the asc though, I didn't know you were providing those. That's great news because it means I can drop the SHA256 test (and myself as the manual arbiter of what is the "true hash") and just use GPG to verify the tarballs. Love it, because I can finally automate that process and get rid of the manual updating.

Now, I will have to write in the logic to detect if a version lock is wanted, then hit the new path of https://download.rocket.chat/build/rocket.chat-{version}.tgz, which is no big deal but I think that's what he was "disagreeing" with.

Ok, yeah that makes sense. This is personally my preference as well. In production I never link to "latest" or "stable" I always tag a version.

Fortunately I don't see any reason for it to change again. Now instead of relying on our website "app" to do redirecting. Links are directly to the files, which should help.

Nice @ the asc though, I didn't know you were providing those. That's great news because it means I can drop the SHA256 test (and myself as the manual arbiter of what is the "true hash") and just use GPG to verify the tarballs. Love it, because I can finally automate that process and get rid of the manual updating.

Yes we started doing that and actually make use of it only in our docker image build. But hadn't made use of it anywhere else. I can imagine updating every time is pretty annoying.

Let me know if there is anything I can do to help 👍

Heads up with this issue if you run into get_url problems: https://github.com/ansible/ansible/issues/31998

Cloudfront requires SNI support and that's currently broken if urllib3 is installed

Bug here has been hotfixed to master in https://github.com/RocketChat/Rocket.Chat.Ansible/releases/tag/v2.2.5

Closing this in favor of two branched issues that were raised. #50 and #52