Supply a prebuilt image in Dockerfile

[MaxDesiatov]

The only downside I currently see with this approach is that Dockerfile references the latest tag, while some actual release tag would be preferable. The latter means that on every release you would have to upload a new image and bump the release tag in Dockerfile.

Maybe using latest is fine for now, but should there be a corresponding CI action here that pushes new images on every commit to master?

[mattt]

Thanks for looking into this, @MaxDesiatov. I started on an alternate take with #185 that presupposes an existing container image on Docker Hub. I think this approach lets us avoid the awkwardness of multiple Dockerfiles. Here's how I imagine things working:

• For each tag, we publish a new image to DockerHub (e.g. swift-doc:1.0.0-beta.5)
• We then re-tag that new image as swift-doc:latest
• This process is automated using GitHub Actions

The current swift-doc:latest was generated by me on my local development machine based on the 1.0.0-beta.4 tag. To test this, I changed our fork of Alamofire to target the SwiftDocOrg/swift-doc@prebuilt-docker-image action in its documentation workflow. Everything appears to be working.

If everything looks good to you with #185, I'll merge it into master. Once I do that, all subsequent runs of the SwiftDocOrg/swift-doc action @master will start using the prebuilt container images — no changes required.

Going forward, we'll need to do a few things:

• Figure out a versioning scheme for actions (GitHub's official actions use v1 / v2, but there may be a better solution coming)
• Figure out a migration strategy for when we update the default branch name from master to main