Prerelease download URLs should be stable

[jackfirth]

Images built with dockerfiles ought to be reproducible. This means that the installer download URL, which for the current prerelease is http://pre-release.racket-lang.org/installers/racket-6.10.1.900-x86_64-linux.sh, should always be available from that URL in the future. I'm not able to find installers for old prereleases at http://pre-release.racket-lang.org/installers so I suspect that's not the case currently.

cc @samth

[stamourv]

I (think I) understand why reproducible dockerfiles are important in general.
In this particular case, though, I'm not sure it's that important, and the cost of making it so is non-trivial.

Pre-releases are meant to be ephemeral, only relevant along the way to a particular release. They are moving targets, and certainly should not be used long-term.

As a meta-point, I'm not 100% convinced that docker is the right tool for this purpose (i.e., automating release testing), but I'm willing to trust @samth's judgment on that. I definitely think, though, that this is an "off-label" use of docker, and that the usual best practices may not apply, or at least may not be worth the effort in some cases.

[samth]

I understand what you mean about this being not something we intended for pre-release builds, but I don't know what you mean about "off-label use of Docker". The point of Docker here is to have a consistent environment that we control to do the testing in so that we always get the same answer, regardless of what machine we run it on, and so that running these tests doesn't change the host system -- both exactly what Docker is for.

[stamourv]

Disclaimer: my knowledge of docker comes from having read some blog posts at some point. Nothing more.
My understanding was that the point was to have consistent, uniform environments for deploying copies of services. We're not really doing deployment in that sense, and we're not really looking for consistency (what we download changes every release, etc.).
It seems the use case we're having here is "cheap, easy to spin up VM", which (IIUC) docker can do, but (again, IIUC) not what it's designed for.

As I said, I trust your judgment that this is a useful tool for this job. But looking at @jackfirth's comments, it looks like the usual way of using docker may not be what you want. I may be way off, though.

[samth]

The point is "consistent, uniform environments" -- it just happens that it's good for services because of that. I think "cheap, scriptable VM-like thing" is exactly what Docker is designed for.

If we had unlimited resources, I'd make all the pre-release builds available forever at stable URLs, but I understand why we aren't doing that.

[jackfirth]

Pre-releases are meant to be ephemeral, only relevant along the way to a particular release. They are moving targets, and certainly should not be used long-term.

This I find interesting, as (I think) it means any bugs found in a prerelease can't be indefinitely reproduced because the prerelease installer won't be available in the future. I think it's worth opening a discussion somewhere more central to Racket about build reproducibility and what Racket's immediate and long-term goals are in that area.

My ideal setup is a set of Dockerfiles that can build Racket installers, images, and all other artifacts straight from the Github repositories, with repeated builds yielding byte-for-byte identical artifacts. But as @samth said we don't have unlimited resources.

If hosting fees and similar operational costs are a concern, we could explore more free-for-open-source tools and services. For example, Docker Hub offers unlimited free public image repositories. Putting installers in images would make them publishable on Docker Hub and available indefinitely for historical / reproduction purposes.