Docker Support

[FreSchNDE]

Hello, since I had a personal need for this, I created documentation on how to run the bot application with Docker, including instructions on how to self-host the MongoDB database for the subscribe module.

All that is required for operation with Docker is the Dockerfile in the same folder as the executable. Users can then create a local Docker image by using simple commands, as described in the new “docker.md” documentation.

This method can be easily integrated into the current repository, there is no need to worry about creating an “official” image or handling another release plattform.

I have changed the GitHub release workflow so that the Dockerfile is only included in the Linux 64 bit release. Linux containers can be executed by Docker almost universally on all host systems, and they are performant. I have tested these changes with the workflow "TestRelease.yml" and they seem to work. (I will gladly remove this file as soon as it has been acknowledged.)

I have tested both approaches described in the new documentation on a Windows 11 PC with Docker Desktop and, based on my experience with Docker, I am sure that they will also work on, for example, Debian Linux environments.

This solution is not perfect. Theoretically, the entire compilation could be outsourced to the Dockerfile, or Docker images could be automatically sent to the Docker Hub with workflows, but I'm not familiar enough with that. In addition, the bot application is not stopped correctly when its container is stopped. The application (or the container?) does not react to the “SIGTERM” signal. This only manifests itself in the 137 exit code and has no further implications. Once again, I'm not familiar enough with C# to fix this.

I had to adapt the code for the clearstate command, so a new release is needed.

[bman46]

@FreSchNDE Thanks for your contributions! I have added a couple comments to the code to discuss/fix prior to merging.

[FreSchNDE]

Ok, I've changed the requested things. I'll now try to implement a GitHub Container Registry Workflow.

[FreSchNDE]

Ok, I don't know how to properly load the files from the Linux 64 bit release into a new workflow (or a new section in the already existing workflow). Unfortunately, I don't have time to deal with GitHub workflows at the moment. I don't want to upload AI generated code.

The Dockerfile is not designed to create an image from the files of the repository, but from the files of the already compiled Linux 64 bit release.

Either I modify the Dockerfile to do the compilation when building the image (but then there are two independent build processes, one in the Dockerfile and one in the regular GitHub AutoRelease workflow), or I figure out how to properly operate on the Linux release data with a separate workflow or a new section in the existing workflow (which I don't have time for right now).

I propose to either merge the pull request in its current state (then users will have to create their own local images as described in the MD file) and I will look into a solution for the GitHub repository in the indefinite future, or the request will remain open until then / someone who knows their way around GitHub workflows takes over.

@bman46 please leave a short reply with what you think is best.

[bman46]

When I have previously generated docker images for C# apps, the compiler would handle the architecture and platform during the build process without needing to specify it. See https://github.com/CyberLions/discord-bot/blob/csharp_master/CCSODiscordBot/Dockerfile for an example. It separates each part of the build using tags so only the relevant files are carried to the final image.

That repository also has a build pipeline that should be able to be reused with minimal modifications: https://github.com/CyberLions/discord-bot/blob/csharp_master/.github/workflows/docker-publish.yml. This compiles for both linux/arm64 and linux/amd64.

[FreSchNDE]

The project you linked builds the executable with commands defined in the Dockerfile.

If you give me the go ahead, I can adjust my Dockerfile to do the same. That means that there will be two (more or less) identical building processes. One for the regular release (inside AutoRelease.yml), and one separate one for the Docker image (defined with Dockerfile and run inside an extra workflow).
I'll be able to easily separate the Docker Image building into a separate workflow that way.

The way it currently is, the Dockerfile just repackages the files from the Linux release, no separate building required.
This way, redundancy is avoided. However, I don't know how to archive that inside of a Workflow, since I don't know how to get to the files of the Linux release. (So the user has to do the building manually, as is described in docker.md)

Let me know what I should do. If you could give me a hint on how to get the files from the previous release inside a new workflow, I could keep the current Dockerfile and avoid redundancy as well as keep the current docker.md (and just expand on it).

[bman46]

If fine with rebuilding the program in a docker image workflow, even if it costs more worker time and is redundant. I'm pretty sure VSCode will identify the docker image as a build target, so I can test changes locally before releasing.

[FreSchNDE]

Hey, sorry for the late answer, I'll continue work sometime in August.

[bman46]

All good. Thanks for the update!