Please switch to Package Cloud/Bintray/GitHub for provisioning

[michaelklishin]

Team RabbitMQ has plans to turn rabbitmq.com/releases and rabbitmq.com Debian repo into read-only archives in a few months and fully switch to Bintray/Package Cloud/GitHub for artifact distribution and repositories.

It would be great if this image could switch to e.g. Package Cloud before that. Nothing is going to break for currently released versions but new ones likely won't be available.

I'm happy to look into a PR if @tianon and @yosifkit share their opinion on which source(s) they prefer and what would be the best migration path.

[tianon]

Thanks so much for the heads up on this change! 😄 ❤️

I started taking a look at the artifacts in the two APT repos (to figure out which we should use), and realized we might as well just use the opportunity to normalize the Debian and Alpine dockerizations a bit more, so I think pulling both from GitHub probably makes the most sense (since the ..._all.deb is published there too). The GitHub tags are a bit of a challenge to programmatically generate given just a version number, so I think we ought to have an ENV for those populated via ./update.sh.

Also, this should make it easier for us to add 3.7 with the now rc.1 release (ala the discussion in #183). 😄 👍

As of right now, I've managed to consume the .deb from GitHub directly which should have zero effect on the user experience (unless users are doing something bizarre like pulling our image and updating RabbitMQ in-place, which certainly isn't something we officially support), and the image size remains identical (which is good, considering literally nothing in the end result should actually be different except the loss of the /etc/apt/sources.list.d/rabbitmq.list file 😆).

If you want to make the PR, I'm happy to push up what I've got somewhere and let you take over, but I'm also fine with just taking responsibility for getting this one done. 👍 (Don't want to steal your thunder, so to speak!) ❤️

[michaelklishin]

Oh, I don't mind others doing the actual work ;) Why are GitHub tags difficult to generate programmatically, though? Up to 3.6.x they have been pretty consistent. 3.7.0 might use a different version but if anything, it is more straightforward since we dropped the rabbitmq_ prefix and use dots instead of underscores.

[tianon]

Right, I didn't mean difficult in the sense of impossible, but difficult in that the logic for doing so is slightly more than "put version number in URL and gogogo", and we'll have to scrape those pages anyhow during ./update.sh (to get the exact Debian version number, for example), so we might as well just embed that directly in the Dockerfile at ./update.sh time to keep the Dockerfile simpler and more straightforward (and with my current in-progress update.sh changes, it'll automatically detect which of the two formats is being used, so we can seamlessly update to 3.7's newer/simpler format). 👍

[michaelklishin]

Replacing the entire URL is fine and what we do in the Chef cookbook. Debian package revision number is a separate value still but it is almost always 1.

[tianon]

@michaelklishin ok, cool 😄 ❤️

I figure the Debian revision will pretty much always be -1, but the goal is to try to isolate us from any unexpected future turbulence as much as we can. 😇