Related to issue #83: Added support for container image

[tuxiem]

Added:
dockerfile
docker.md documentation on usage and build-it-yourself
workflow for building and pushing container image to gchr.io

Might need edits in .github/workflow/docker.yml to work, if the ${{ secrets.GITHUB_TOKEN }} needs permissions.

[patrickdappollonio]

Hey @tuxiem!

Thank you SO MUCH for your contribution and apologies I couldn't get to this faster. This is great so far, I only have a handful of concerns, namely whether using alpine is a good idea, and perhaps switching into something else.

Additionally, this project uses .goreleaser.yml but the code you proposed does not take advantage of that. Instead it defines its own flow. You could leverage goreleaser to do most of the heavy lifting for you. Another project of mine creates a dockerfile like this:

https://github.com/patrickdappollonio/http-server/blob/master/Dockerfile

And then it's referenced from goreleaser like this:

https://github.com/patrickdappollonio/http-server/blob/master/.goreleaser.yml#L29-L41

So then both testing and releasing pipelines are just a matter of using goreleaser each time, like here (for a version release) or here for a PR review test (it's called Dry-run goreleaser).

Let me know what you think! If you think this is something you could do, I will be more than happy to take it and would appreciate your help tremendously! If not, I completely understand it. What I would do then is take over your pull request to add the additional changes, then add the remaining ones, so you're credited where it's due.

Let me know!

[patrickdappollonio]

We might need to have a way to test building (but not releasing) the container for commits, so people know nothing breaks on the container side whenever they propose a change.

[tuxiem]

I'll need to investigate on that part

[patrickdappollonio]

For this, I'm a bit opinionated, but four versions should be released if, say, we're releasing version 3.7.4 (as an example, we don't have that version but let's assume we do):

• latest, as in overriding the latest tag
• v3
• v3.7
• and finally v3.7.4

This is because this repo tries to follow Semver, so people that need the guarantee that no major breaking change appear in a minor change can confidently pull the newer version of the image. If I ever do, that's on me, not on the people maintaining these apps deployed to environments.

I do something similar here: https://github.com/patrickdappollonio/http-server/pkgs/container/docker-http-server although with no minor version, just major and patch, and this has proven to work in corporate environments where that stability can be called out during usage.

[tuxiem]

@patrickdappollonio I will review this when I have some time - I expect it to be around the new year.

[patrickdappollonio]

No problem and completely understandable! Happy to discuss if you have any questions after the new year! Thanks again for your help and willingness.