Unify Docker tags for amd64 and arm64 architectures

[sonroyaalmerol]

This is just another option if we want to unify the tags for both architectures.

The workflow is not as straightforward as it used to since we're using different Dockerfiles and different base images. Builds are made, pushed into a file, and uploaded as an artifact. The artifacts are then downloaded and pushed into a local registry before getting pushed to Docker Hub in one tag by another job. I'm not sure if there is a simpler way to do this.

[thijsvanloef]

Hi! I'm not sure if this is the way I want to move forward with the images. This is easier for the user, this is a pretty complex system to maintain. I'll have to think about it

[USA-RedDragon]

Just wanted to share my take on the same concept: USA-RedDragon/palworld-server-docker@e1fc828, which has a lot less code impact (6 changed files with 57 additions and 210 deletions.)

There's no real magic to it, it uses:

• the Docker-provided $TARGETARCH build argument to choose which base image to use
• opts to build gorcon for both arm64 and amd64
• swaps for the arm64v8/golang:1.22.0-bullseye image for official golang alpine image when building gorcon
• disables CGO for gorcon compilation so that the GCC compiler toolchain doesn't have to be installed and the binary is portable
• removes the deprecated go get command since go build will resolve any missing dependencies based on the go.sum file
• uses the $TARGETARCH build argument to choose which SHA1SUM to check against per-architecture
• and basically cuts the CI workflow YAMLs in half

I can make this a PR, but I didn't want to step on any toes since it's the same goal as this PR.

With this solution, no users will have to specify -arm64 tags since Docker will resolve the appropriate architecture image automatically.

[sonroyaalmerol]

Just wanted to share my take on the same concept: USA-RedDragon@e1fc828, which has a lot less code impact (6 changed files with 57 additions and 210 deletions.)

Man, I was so tunnel visioned on the GitHub Workflows and didn't even think of just unifying the Dockerfile itself. This is indeed an option with a lot less deployment magic. I don't mind you having this as a PR.

One concern though is if in the future we have a dependency that needs to be manually build in one architecture (like rcon-cli), we'll probably need to build it for both in your method, right? This is fine right now as rcon-cli is made with Go and has relatively fast build times. I had this concern with a different PR of mine #337 (comment). The build times of the image will probably be a lot longer if I went the Rust tool route.

But, I guess it really wouldn't matter much as the arm64 build times would still be the bottleneck in both approach. I can close this in favor of your PR.

[sonroyaalmerol]

Closing in favor of #364