add workflow for docker build

[krombel]

This builds a docker image.

Only push to ghcr.io if it was pushed to master or triggered by tag

[poVoq]

Seems good. Can you also add a notice about how to access these in the documentation and the changelog please?

[krombel]

Done. I hope it is ok like this

[jugendhacker]

As noted in the chat: this seems to increase the CI runtime significantly. Would it make sense to not run it on every PR?

[DasSkelett]

It's primarily the emulated arm64 compilation taking this long:

#13 [linux/arm64 builder 3/3] RUN apk --no-cache add go git         && cd /go/src/matterbridge         && CGO_ENABLED=0 go build -ldflags "-X github.com/matterbridge-org/matterbridge/version.GitHash=$(git log --pretty=format:'%h' -n 1)" -o /bin/matterbridge
#13 DONE 984.1s

There's in theory the trick to use (C)Go's cross-compilation on the native architecture instead of "normal" compilation within QEMU, but I couldn't get it to work in GitHub actions with an Alpine base image the last time I tried for one of our projects (which was two years ago or so, so the situation might have changed).

Maybe a simple compromise would be building amd64 everytime and arm64 only on master push and/or tags. Of course there's the risk of it breaking without anyone noticing in a PR, but that might be an acceptable and low enough risk, as we're talking Go here.

Apart from that what might still make sense regardless is something like this in the builder step in the Dockerfile to avoid having to redownload all dependencies on every build even if they don't change, saving some bandwidth and time:

FROM [...]
COPY go.mod .
COPY go.sum .
RUN go mod download
COPY . /go/src/matterbridge
[...]

Also the .dockerignore could be expanded so you don't re-copy and thus re-build when only the docs or README changes, although you could also skip the entire workflow in this case.

[poVoq]

Maybe a simple compromise would be building amd64 everytime and arm64 only on master push and/or tags. Of course there's the risk of it breaking without anyone noticing in a PR, but that might be an acceptable and low enough risk, as we're talking Go here.

This sounds good. @krombel could you adjust your PR accordingly please? Or just drop the automated builds of the arm64 containers entirely (I know from another project that Alpine based images have problems with those right now due to an upstream issue). Thanks!

[krombel]

i would like to have the arm build as well so I kept it in the final build but excluded them from PRs.
Included the other comments as well to enhance cache-ability of the build

[poVoq]

LGTM & Thanks for the contribution 👍

[DasSkelett]

Could it be that you need to enable the container registry in the repo settings, or make it public @poVoq?
Nothing shows up at https://github.com/matterbridge-org/matterbridge/packages or ghcr.io/matterbridge-org/matterbridge yet, but according to the workflow the push went through fine.

[poVoq]

Looks like it was set to private. I changed that to public now.