feat: add Docker image build on prod release and publish to ghcr.io

[yitsushi]

This patch add a simple Docker image that builds the application with node and puts the end result into a small nginx image.

Updtaed the prod release GitHub action to build and publish the image on GitHub's OCI registry (ghcr.io) and connect it to the repository.

Why?

Docker is fun, more and more people deploy images on their homelab, Docker Swarm, or Kubernetes clusters. I do the same. First I build a builder for myself¹, then I had a "waaaaait a minute...." moment and realised I can upstream it and put it here.

Another options for the GitHub action:
I can move the whole build to a separate workflow and trigger on new tag and instead of building the application, just download the artifact from the release page on GitHub (like my version² does on manual trigger).

Footnotes

1. https://github.com/yitsushi/phanpy-docker/pkgs/container/phanpy-docker ↩

2. https://github.com/yitsushi/phanpy-docker/blob/main/.github/workflows/build-and-publish.yaml ↩

[yitsushi]

If you think this can live in the official repo, please let me know if you prefer a separate GH action for the build and publish or keep it in the same prod release workflow.

[yitsushi]

It's very similar to #466 with the addition of GitHub workflow. I'm happy with either solutions, I just prefer to have a docker image and building on promotion makes it less painful to release.

Why I opened this PR? Because I was lazy and didn't check if there is an open PR for that, I only checked if it has an official docker image or not.

Feel free to close in favor of that PR.

[cheeaun]

Thanks for the PR!

I thought about this and thinking that it would be better if this is done separately from official repo, as I'm not the one maintaining this and I don't plan to spend time or learn how to maintain this 😬. This would allow different docker images of Phanpy, and I'll put a section linking them on the README.

The GitHub action does make sense as I wonder how you guys are going to sync the new builds/versions/updates.

So, questions:

• Is it possible to trigger docker builds without GitHub Action set on the official repo? Maybe trigger GitHub action from your own repo based on push or releases from a this (remote) repo 🤔. Or, maybe there's some webhook thing to auto-trigger this?
• I personally recommend the "custom build", so I'm thinking if it's possible to trigger a docker build with custom env variables? I'm not sure, maybe when other devs pull or build the published docker image, they can pass in their own env variables somehow?

Tagging folks from #466 @AlyxPink @burntcookie90 @benjaoming

[benjaoming]

This looks great! This is also the recipe, I've followed and tested. Bravo @yitsushi 👏

If you can have a look here, it'd be nice to have some follow-up discussion around security headers in Nginx: #479

Edit: While I see nothing wrong in the PR itself, I can see reasons why an official Docker image is less preferable to having a Dockerfile template as documentation. Especially because npm run build accepts a lot of important customizations to the build.

[yitsushi]

GitHub actions doesn't allow cross repository triggers, all repositories I worked on resolved this by a cron-job that checks if there is a new release on the upstream repo.

this is done separately from official repo, as I'm not the one maintaining this

Totally makes sense, I'll just set one up for myself with a cron job to auto build. Right now it's manual, I added the rss feed of the repo's release page to my reader and when a new one is release I just kick off a new build.

[benjaoming]

I personally recommend the "custom build", so I'm thinking if it's possible to trigger a docker build with custom env variables? I'm not sure, maybe when other devs pull or build the published docker image, they can pass in their own env variables somehow?

I'm with you on this one @Phanpy - building this image isn't complicated, and to be able to use Docker build-args could be a nice way to customize features - or just straight-up editing the npm run build command in a local Dockerfile before building the Docker image.

I probably wouldn't use an "official" Docker image released from the repo, exactly because having your own Dockerfile (nice to be able to copy from a documentation template), can give the flexibility needed to tweak small things easily.

So to suggest a simplification here, it would be to move the Dockerfile that @yitsushi suggests into the documentation and then continue to work on this template as "best practice" until maybe one day there's a strong reason to push it as an officially maintained docker image.

[yitsushi]

Well I prefer official¹ images because I can spin up a test container to see how it works, deploy easily without the need of

1. creating a dockerfile.
2. create a repo for it, so it's in a save place.
3. build the docker image every time.
4. store it somewhere in an OCR repository (dockerhub, ghcr, etc).

I'll not build docker images on the server my applications running, if I'm not at a computer where I can build one, the application will not be updated until I can sit down somewhere to build it (that's why I spend extra time creating github actions with manual triggering²). It's a lot more work and resources if I can access my raspberry and build there because that's arm and my VPS is not arm, so that's xbuild.

That's a lot of extra work instead of just using an image, even get notifications when new image is available and just update the image tag.

Footnotes

1. Official, or at least something that's not like a "I built it once, use :latest, be happy, and maybe I update it sometimes, maybe not". ↩

2. Like this: https://github.com/yitsushi/phanpy-docker/actions/workflows/build-and-publish.yaml I just start a new build when I get notifications from Releases RSS feed. ↩

[yitsushi]

Created a Discussion, I think that's more easier to follow and fits more: #511