Dockerfile, build, and push to registry

[ByFox213]

This is a question about the current Dockerfile: what is its purpose? As far as I can tell, nothing triggers it directly, and it's not used by any CI/CD pipeline.

My proposal is to have the server built automatically via CI/CD and then published to a registry like ghcr.io. The main benefit is convenience—instead of users building it themselves, they can simply pull and use a ready-made image.

I initially submitted this as a pull request to ddnet-insta, but chillerdragon mentioned they would prefer to see it implemented in the main ddnet repository so all forks can benefit from it.

I expect this will likely lead to some discussion.

[AssassinTee]

do you know to what degree we can automate that? Like also do automatic tag releases and latest stable and nightly?

[def-]

We currently have a build setup, see https://github.com/ddnet/ddnet-scripts/tree/master/release It would be cleaner to use Docker for that, and generate the official builds there, as well as docker images. But that's quite some effort, and I probably don't have time for that. The macOS builds also can't be done on Linux, so they'd have to stay separate. Creating yet another additional build system, in addition to the official builds, and CI builds, seems like a bad idea. We should rather unify them.

[ByFox213]

We currently have a build setup, see https://github.com/ddnet/ddnet-scripts/tree/master/release It would be cleaner to use Docker for that, and generate the official builds there, as well as docker images. But that's quite some effort, and I probably don't have time for that. The macOS builds also can't be done on Linux, so they'd have to stay separate. Creating yet another additional build system, in addition to the official builds, and CI builds, seems like a bad idea. We should rather unify them.

This proposal primarily concerns the server side, not the client side.

I suggest building the server via cicd based on specific events (for example, when a tag is created) and hosting it on ghcr.io for quick setup.

In general, I really don't like servers running as root or a regular user. I prefer to run them in a container.

example cicd: # from pr ddnet-insta

name: Build, Push, Deploy
on:
  push:
    tags:
      - 'v*'
  workflow_dispatch:

jobs:
  build-push:
    name: Build docker image
    if: "!contains(github.event.head_commit.message, '[skip ci]')"
    runs-on: ubuntu-latest
    steps:
      - name: Check out the repo
        uses: actions/checkout@v6

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

      - name: Log in our registry
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          file: Dockerfile.server
          push: true
          tags: |
            ${{ secrets.DOCKER_USERNAME }}/ddnet:${{ github.event.release.tag_name }},
            ${{ secrets.DOCKER_USERNAME }}/ddnet:latest
          labels: ${{ steps.meta.outputs.labels }}

This is a Docker Hub release, but it's easy to change. If you like the idea, I'm willing to work on it.

[ByFox213]

do you know to what degree we can automate that? Like also do automatic tag releases and latest stable and nightly?

There's so much that can be automated^^ But the question is, is it necessary?

[AssassinTee]

Is this CI script generated ? (it's bonkers)

There's so much that can be automated^^ But the question is, is it necessary?

Yes, we don't want to manually build docker with each release. If we can do this in a manner, that no maintainer has extra work that would be good.

and CI builds, seems like a bad idea

Why are they a bad idea?

[def-]

Why are they a bad idea?

One more constraint to make sure keeps building and being correct. We'd have to test the docker image that is generated too.

I don't like the idea of having 3 separate ways of building, there should be one ideally.

[AssassinTee]

One more constraint to make sure keeps building and being correct. We'd have to test the docker image that is generated too.

Aren't the integration tests doing that for us? I'd hook up the docker build step as an optional step behind the build, just getting the artifacts.

I could also imagine doing the integration tests on the docker (server) in addition

[heinrich5991]

My proposal is to have the server built automatically via CI/CD and then published to a registry like ghcr.io. The main benefit is convenience—instead of users building it themselves, they can simply pull and use a ready-made image.

You can already download the releases from the website, does that not work for you on servers?

What additional value does this docker image provide?

[AssassinTee]

What additional value does this docker image provide?

I guess it's just easier to "plug and play" a docker container tbh, at least if done well

[ByFox213]

You can already download the releases from the website, does that not work for you on servers?

If we talk about my case, no, I use kubertenes(talos) os mainly on servers, you can't download and run something there, necessarily only in containers :)

What additional value does this docker image provide?

It will be convenient to launch servers through the use of a single yaml file, if ddnet itself collects them, this will remove the assembly action and the creation of a dockerfile.

[heinrich5991]

I think this should be done outside of DDNet. We already provide archives that you can directly unpack into your docker container.

[ChillerDragon]

@heinrich5991 the ddnet published binaries do not work for forks of ddnet which made edits to the code. I think what @ByFox213 is after is the convenience of cloning ddnet and making changes to it and then running a docker build command.

@ByFox213 did I get that correct? Or what is your use case here? You want to get the code with a COPY . . and not with a RUN wget ..?

[ByFox213]

@ByFox213 did I get that correct? Or what is your use case here? You want to get the code with a COPY . . and not with a RUN wget ..?

COPY :)

[ChillerDragon]

We already provide archives that you can directly unpack into your docker container.

This is not user friendly. Users want to be able to just do docker run ddnet/ddnet:19.5 no further setup needed.

[heinrich5991]

You can do that today, no need for help from DDNet. We also don't have Debian's packages in the repository, or Arch Linux's. You can build your own docker containers for others to use, conveniently.

[ChillerDragon]

Actually I can not.

$ docker run ddnet/ddnet:19.5
Unable to find image 'ddnet/ddnet:19.5' locally
docker: Error response from daemon: pull access denied for ddnet/ddnet, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

Run 'docker run --help' for more information

[heinrich5991]

Actually I can not.

What I meant that you can publish these docker containers and others will be able to use them.

[ChillerDragon]

@heinrich5991 thats not what I meant. I mean that usually projects provide their own official images. We could do this quite easily. @ByFox213 already built the Dockerfile for it and the CI/CD fully automates the publishing.

[heinrich5991]

thats not what I meant. I mean that usually projects provide their own official images. We could do this quite easily.

If it's done easily, just do it (outside this repository).

We don't need to put DDNet into n+1 package managers, people using these package managers can do it themselves. It's the same as for Debian, Arch Linux, Flathub, …