Automatic docker releases

[jmattheis]

Gotify depends on the debian-slim image which should be updated regularly to get the most recent bug/security fixes. We should add a github action that automatically releases gotify to use the latest base image.

[eternal-flame-AD]

The multi arch image I was working on already has configurable base image on the docker build arguments. I'm not sure how to integrate it into the https://github.com/gotify/build ecosystem though. Maybe put this configuration logic there, and we tag the container by release version (and alias the newest tag to the current unversioned tags?)

server/docker/Dockerfile

Line 1 in 7c17433

ARG DEBIAN=stable

[eternal-flame-AD]

We should also do SBOM attestations for images so vulnerabilities can be analyzed for each layer and maybe more permissible for company security policies on using our software. My WIP should be compatible with that too.

https://docs.docker.com/build/metadata/attestations/sbom/

Here's a container I packaged:

Details

[jmattheis]

Maybe put this configuration logic there, and we tag the container by release version (and alias the newest tag to the current unversioned tags?)

Could you elaborate? I don't quite understand what you mean or how this is related to this ticket. Do you mean re-releasing an existing version e.g. 2.5.0 with an updated base image?

[eternal-flame-AD]

The concern is about compatibility with existing plugins which uses the above image and are not aware of base image differences.

The current plugin template only considered go version but not the base image version. I think we should have both the traditional tag and a different tag that looks like gotify-v1.1 (we don't need arch anymore because it will be multi arch) and alias the newest tag to the traditional go-version-only tag syntax. (In practice, if you release v1.1.1 which only update the container itself, you reset the legacy tag of the same Go version here.

https://github.com/gotify/plugin-template/blob/7f7ad4153075f8656be1e1642040d300fdb1057c/Makefile#L34

[jmattheis]

The current plugin template only considered go version but not the base image version. I think we should have both the traditional tag and a different tag that looks like gotify-v1.1 (we don't need arch anymore because it will be multi arch) and alias the newest tag to the traditional go-version-only tag syntax. (In practice, if you release v1.1.1 which only update the container itself, you reset the legacy tag of the same Go version here.

Sorry, still don't 100% get it, do you want to make the gotify/build image multi arch? And do you mean releasing one gotify/build image with an updated base image?

I don't think we really need multiple releases for one Go version in gotify/build as Go is released every month, so we can go along this pattern and have ~1month up-to-date build images.

I originally only meant the gotify/server base image https://github.com/gotify/server/blob/master/docker/Dockerfile#L1 in this ticket. I don't think the gotify/build image matters much (with the exception to being consistent for gotify/server and plugin builds), as we basically just compile the go stdlib into the binary and the rest is dynamically linked.

[eternal-flame-AD]

Oh I get your logic now, sorry I misunderstood how you want to handle the release cycle.

I was thinking about making it multiarch too to provide the same multiarch build for plugin authors but it may not be related to this issue now that I understand what your intentions were.

Yeah this feels doable, I already wrote a CI to follow gotify release for my plugins I can probably give this a try.

[jmattheis]

I was thinking about making it multiarch too to provide the same multiarch build for plugin authors but it may not be related to this issue now that I understand what your intentions were.

I mean if you want to support this feel free, but I think getting cross compilers for all architectures working on all architectures will be some effort. And building these will be pretty slow without natively building.

[eternal-flame-AD]

I agree it's low priority, the primary use is probably not cross compiling but users want to build their plugins on the target device itself, so far no tickets yet so maybe you are right no one has had this problem yet