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.

[Robin-Sch]

Okay, I'll take a look tomorrow to get this PR merged. Just to confirm I am not missing anything, the only changes needed are:

• Move Dockerfile to src/contribs/docker/
• Add note about Docker in README
• Add Makefile
• Mention/use davmail -token

[esabol]

Okay, I'll take a look tomorrow to get this PR merged. Just to confirm I am not missing anything, the only changes needed are:

• Move Dockerfile to src/contribs/docker/
• Add note about Docker in README
• Add Makefile
• Mention/use davmail -token

I would still advise retaining and moving the existing src/contribs/docker/ to src/contribs/docker_alt/ (or something like that).

[Robin-Sch]

Okay, let me know if something else should be changed!

[Robin-Sch]

@mguessan @esabol please let me know if there's anything missing to get this merged!

[esabol]

Nitpick: Change "davmail in docker" to "DavMail in a Docker container".

Other than this minor change, everything looks good to me. 😄

[mguessan]

I started working on merging this contribution:

• moved to src/docker
• build jar only, no need to build all release packages
• add openjfx to build dependencies (O365InteractiveAuthenticator is not included without OpenJFX)
• improved ant build to match debian/docker context
• add git-svn dependency for build version check
• removed swt depency not working inside docker

I managed to push a first version of the package to Github, however workflow is not yet in place, need to make sure it's stable first.

In addition I had some trouble to make the interactive part work, in wayland docker apps can't connect to X11 display, however even back to X11 it's still not stable

Last point: DavMail is unable to access /config volume, need to investigate

[esabol]

I use X11 and have very little experience using Wayland, but I think this is how to run a Wayland client inside a Docker container:

docker run --rm \
      -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY \
      -e XDG_RUNTIME_DIR=/tmp \
      -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
      --user=$(id -u):$(id -g) \
      imagename waylandapplication

Oh, the desktop OS you are using and the OS in the Docker container both need to be configured to use Wayland.

[esabol]

@mguessan wrote:

Last point: DavMail is unable to access /config volume, need to investigate

The docker command in the Makefile includes the arguments -v ./config:/config (and similarly in the docker compose.yml file). So it's expecting your DavMail properties file to be located in a config subdirectory located your current working directory. If your DavMail config file has a different file name or location, then you may need to adjust those things accordingly. For example, my DavMail properties file is located at $HOME/.davmail.properties, so I would use the arguments -v $HOME/.davmail.properties:/config/davmail.properties instead. Either that or copy $HOME/.davmail.properties to my current working directory as config/davmail.properties. The other possibility that might be causing access problems is if the user ID running davmail inside the container doesn't have read/write permissions on the config file outside the container. The --user=$(id -u):$(id -g) arguments should take care of that. I apologize if you already knew some or all of this.

[mguessan]

Github workflows merged, had to grant actions access to packages and also make package public (by default it was private).

BTW found the root cause to my volume access issues: selinux was enabled on VM !

[esabol]

BTW found the root cause to my volume access issues: selinux was enabled on VM !

I run into that all the time at work myself!

[esabol]

Github workflows merged, had to grant actions access to packages and also make package public (by default it was private).

This is pretty awesome! One minor thing of no consequence that you might want to tweak:

davmail/.github/workflows/build-release-image.yml

Line 40 in 272312a

- name: Build and push unstable

Change "unstable" there to "release image".

Also, I think some mention of the Docker images should be mentioned in the top-level README.md. The PR had such a change.

What's the full Docker registry path to pull the Docker images tagged by the GitHub Actions workflows?

[Robin-Sch]

What's the full Docker registry path to pull the Docker images tagged by the GitHub Actions workflows?

ghcr.io/mguessan/davmail

Tags can be found here: https://github.com/mguessan/davmail/pkgs/container/davmail

[mguessan]

Ok I applied a lot of adjustments from testing feedback. Main changes are a new DAVMAIL_PROPERTIES environment variable set by default to /config/davmail.properties

The /config volume is mounted from ~/.davmail, need to make sure this directory exists before first docker run to avoid it getting root ownership. The template file is created in /etc inside docker image and copied to /config only if there is no existing configuration.

SWT browser does not work inside Docker so we prefer OpenJFX embedded browser.

Added a link to Docker images on home page README

This should be relatively stable now, will close this PR soon, we can always create new tickets for new issues.

[mguessan]

Closing PR, all changes should be merged in trunk.

Thanks for this awesome contribution.