Remove unused docker setup

[senekor]

I recently updated the heroku deployment and saw that at least the staging environment is not based on docker at all.

@Manishearth is the production deployment different than staging and uses the container? (I only have access to staging on heroku, so I don't know.) It would surprise me in any case.

If the production deployment is not based on docker like staging, I think we can remove the docker stuff.

[Manishearth]

The environments should be the same. But also you should get heroku access

[senekor]

Ah, so it can be useful to test locally in a heruko-like environment? That makes sense. I'll have to update it to make it match the new heroku 24 stack.

[Manishearth]

Oh, yes, that's one of the reasons that's there, though tbh I've never used it. The staging environment solved a lot of these problems, and we've not had complex weird only-shows-up-on-heroku problems, really.

Static site generation would be awesome to move past this mess.

[senekor]

I could see myself working on static site generation. Things that aren't yet clear to me:

• What happens to content that is now truly dynamic? i.e. current rust version and rust team data. Maybe we could add CI tooling that automatically triggers a PR / redeployment if something changes?
• There are some redirects. I actually don't know how to handle redirects on a static site idiomatically. I guess one could add a file that contains javascript which instructs the client to navigate to the redirection target? I might be missing some web standards knowledge here.

[Manishearth]

Maybe we could add CI tooling that automatically triggers a PR / redeployment if something changes?

Yeah I don't know either. Potentially we have automatic rebuilds from main every day, with the ability to trigger a manual one.

I actually don't know how to handle redirects on a static site idiomatically.

use a <meta> redirect. Also possible in the static site