Update check

[casperklein]

Description

This adds an update check, that will (if enabled) send a notification mail to $POSTMASTER_ADDRESS once an update is available.

The check runs on container start and then in a 24 hour interval.

The latest version information is fetched from https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/VERSION

To test this feature, you can trigger a update notification with:

# "downgrade" version and restart update-check
docker exec mailserver bash -c "echo 9.0.0 >/VERSION && supervisorctl restart update-check"

# verify log
docker exec mailserver cat /var/log/supervisor/update-check.log

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (non-breaking change that does improve existing functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (README.md or ENVIRONMENT.md or the documentation)
• If necessary I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[wernerfred]

LGTM on a first sight 👍🏻
What I don't like is that the approach with the VERSION file cannot really be automated in a CI/CD process. The event that would kick of CI/CD is either a new Release or the push of a tag. This could of course trigger a pipeline to update the VERSION to the one matching the tag for example but the docker build then would checkout the specific tag of the repo which would not contain the correct VERISON as this commit happened after the tag push.

One workaround would be to add a step that changes the VERSION after cloning but right before building the image but then it would never be changed in the repository.

No show-stopper but still something to take into consideration as forgetting to update the file will lead to floating update notifications.

[casperklein]

Other idea: Why do we want to automate the update of this file?

Before tagging a new release, bumping the VERSION should be the last PR made. We can use that PR, so that @docker-mailserver/maintainers can confirm, that the to be released version is tested and works as desired.

[polarathene]

You could tag releases via manual Github Action trigger that updates this VERSION file among other things if that's important.

You can also ignore the file approach and query the latest tag via Github API (requires jq installed):

curl -sL https://api.github.com/repos/docker-mailserver/docker-mailserver/releases/latest | jq -r ".tag_name"

[casperklein]

You can also ignore the file approach and query the latest tag via Github API (requires jq installed):

How does the script get the current running version?

[polarathene]

How does the script get the current running version?

Oh I thought that was already available elsewhere like adding into an ENV in the Dockerfile. It could be added via arg during build on tagged release?

Then just query the ENV to compare against?

[georglauterbach]

I too would favor a solution without a file. I have no good solution myself, but the comments I read suggest that we could achieve this without a file.

[casperklein]

Let's move the VERSION file discussion to the related issue #1946

[casperklein]

At the moment $VERSION_URL points to my repo, so the version check can be tested. If this PR is ready for merge, I'll provide a final commit correcting that variable.

[polarathene]

LGTM.

May want to add a brief mention of the ENV vars page and default behaviour in the docs page regarding update/maintenance for the image?

[wernerfred]

LGTM 👍🏻
Thanks for reworking!

Only one small request from my side: Maybe it makes more sense to higher the default check interval? Now that I am writing this 7d seems a bit high as it would only check 4 times in a month but 1d is to short imho as new releases might need a hotfix? Anyways feel free to merge even with 1d, just a thought of mine and if i don't like it personally i can set it to a higher value by myself 😄

[casperklein]

I thought about the same, what would be a sane default check interval. In the end, I went with 1d.

1. Compared to 1h, someone does not get instant notified. That is good, if there are any (minor) hotfixes.
2. Compared to 1w, someone gets security updates pretty fast.

the most problems that occurred after releases were fixed within a week?

If no one would update, because of waiting for a possible hotfix, we wouldn't get aware of any bugs. A vicious circle 😉

if i don't like it personally i can set it to a higher value by myself

That was one reason why i've implemented the UPDATE_CHECK_INTERVAL yesterday 😃

[wernerfred]

LGTM, thanks

[NorseGaud]

@casperklein , was apt-get -qq -y purge gpg gpg-agent &>/dev/null in the Dockerfile intended to be removed? I've got It in a few of my branches and I wanted to confirm it was supposed to be removed (it seems useful).

[polarathene]

was apt-get -qq -y purge gpg gpg-agent &>/dev/null in the Dockerfile intended to be removed?

Yes.

That line was covered in this commit for the PR, the commit message references this Fail2Ban PR, the linked comment and earlier discussion on that PR (which introduced it) should clarify why the line was removed.

The &>dev/null affected debugging and wasn't required, the gpg and gpg-agent packages are provided already via the earlier gnupg package.

[georglauterbach]

@all-contributors please add @casperklein for maintenance

[allcontributors]

@georglauterbach

I've put up a pull request to add @casperklein! 🎉