Update Docker setup

[Robin-Sch]

Hello 👋

I have updated the docker setup such that allows for automatically building and publishing to the github container registry. This way, people can easily download the docker image without building it themselves (similar to just downloading the latest release from sourceforge).

I have also added a compose file for ease of use, so people can you do docker compose up -d and boom, they have davmail running.

In addition, I have also explained how to setup SSL (both using letsencrypt and traefik) and how to use an interactive method even when running davmail on a headless server.

Let me know if you have any thoughts!

[esabol]

I love the GitHub Actions workflows! I'm not sure trunk=stable? @mguessan, can you comment on that? I would suggest adding a manual option to at least the stable workflow.

It would be nice to have a workflow for publishing a specific version and latest tags when a new release is made. Is that possible?

Does the Dockerfile need to be in the root of the repository for the GitHub Actions workflows to work? Otherwise, I'd would prefer to keep it in src/contribs/docker/.

And as someone who routinely uses Makefiles to build my Docker images, I think there's still some value in keeping a Makefile around in src/contribs/docker/ with some useful targets like image, latest, and run. Just my two cents.

[Robin-Sch]

It would be nice to have a workflow for publishing a specific version and latest tags when a new release is made. Is that possible?

Yes this is possible! Will push commit in a bit

Does the Dockerfile need to be in the root of the repository for the GitHub Actions workflows to work? Otherwise, I'd would prefer to keep it in src/contribs/docker/.

I does not need to. Generally speaking most projects keep the Dockerfile and compose.yml in the root so people opening up the source code can quickly/easily see it has a docker image available (and easily download the compose file).
If you want we can put any/both of them in the docker directory, let me know if this is preferred!

And as someone who routinely uses Makefiles to build my Docker images, I think there's still some value in keeping a Makefile around in src/contribs/docker/ with some useful targets like image, latest, and run. Just my two cents.

Honestly, I have never used the Makefile that was there (and I have no idea how to use it). However, the Dockerfile builds davmail based on the files in the current directory.

Building:

git checkout <commit / version>
docker build . -t mguessan/davmail:<version / latest>

Running (with compose.yml in same directory):

docker compose up -d # -> note that this downloads the Docker image from ghcr.io, change the "ghcr.io/mguessan/davmail:stable" in compose.yml to "mguessan/davmail:<version / latest>" for locally built/custom versions

Running (with native docker run commands):

docker build . -t davmail # again, this might take a bit
docker run --network=host --rm --name davmail --hostname davmail -v /tmp/.X11-unix:/tmp/.X11-unix  -e "DISPLAY=${DISPLAY}" -v "${XAUTHORITY:-$HOME/.Xauthority}:/.Xauthority:ro" -v ./config:/config -u "$UID" mguessan/davmail:<version / latest>

I'm not sure how to properly setup the Makefile for this, let me know how you imagine it

[esabol]

Is https://github.com/mguessan/davmail/tags being used (that is, if a new version is released a new tag will be created)? If so, then yes for sure this would be possible

Yes, that's how @mguessan does new releases (by adding a tag with the new version number). The last release was 6.3.0.

Does the Dockerfile need to be in the root of the repository for the GitHub Actions workflows to work? Otherwise, I'd would prefer to keep it in src/contribs/docker/.
It does not need to. Generally speaking most projects keep the Dockerfile and compose.yml in the root so people opening up the source code can quickly/easily see it has a docker image available (and easily download the compose file).

Well, it's up to @mguessan, of course, but the focus of this repository traditionally hasn't been to build a Docker image, so it doesn't necessarily make sense to put those files in the top level like in some other repos.

I do recommend mentioning the existence of the src/contribs/docker/ files in the top-level README.md to improve visibility. More specific Docker instructions, like the stuff you wrote above, could be added to a README.md in the src/contribs/docker/ directory.

I'm not sure how to properly setup the Makefile for this, let me know how you imagine it

I suggest looking at https://github.com/mguessan/davmail/blob/master/src/contribs/docker/Makefile, but that employs a somewhat complicated image building mechanism.

The Makefiles I use for building Docker images tend to be much simpler. I usually do something simple like this:

IMAGE_NAME = mguessan/davmail
IMAGE_VERSION ?= ""

ifeq ($(IMAGE_VERSION),)
       IMAGE_LABEL ?= $(IMAGE_NAME)
else
       IMAGE_LABEL ?= $(IMAGE_NAME):${IMAGE_VERSION}
endif

image:
       @echo "Building Docker image ${IMAGE_LABEL}..."
       docker build -t $(IMAGE_LABEL) .

tag-latest-without-build:
       @echo "Tagging Docker image ${IMAGE_LABEL} with latest..."
       docker tag `docker image ls --format '{{.ID}}' $(IMAGE_LABEL)` $(IMAGE_NAME):latest

latest: image tag-latest-without-build

And you're probably thinking that that's so simple that it's unnecessary, which it might very well be, but I find it more convenient to type make latest than to type out the Docker commands to achieve the same thing. I also started using Docker before docker-compose existed, so maybe I'm just "old school" in this regard. :)

I wonder if the current Docker files should be retained in a src/contribs/docker_alt directory? Maybe someone prefers the existing Docker apparatus. It does have an intriguing test target that might be useful, and it uses an Ubuntu base image which some folks might prefer to Debian.

[mguessan]

A lot of interesting stuff in there, I feel like the existing contribs goal is to run DavMail in desktop mode, this new PR is more oriented towards server mode (see letsencrypt / traefik instructions).

We may want to mention the davmail -token command to not run DavMail, juste create a refresh token.