Hmmm.. Looking at the Supervisor configuration

I do not think the check will run again.. The documentation for Supervisor says the default is autorestart: unexpected. The exit 0 should indicate a normal exit. @casperklein can you verify?

@vincentDcmps could you please elaborate a bit on the behavior that you are seeing exactly?:)

Something else is odd though: @casperklein @polarathene please have a look: https://github.com/docker-mailserver/docker-mailserver/pkgs/container/docker-mailserver Why was :edge not updated yet? :latest is equal to :13.0.0 but :edge is not..

edge is not update because cron is executed only on fifth day of week

.github/workflows/scheduled_builds.yml

name: 'Deploy :edge on Schedule'

on:
  workflow_dispatch:
  schedule:
    - cron: 0 0 * * 5

I'am agree with you if I read supervisord docs my issue doesn't have to happen
the issue was that I have received 5 mail by minute to inform me that update is availlable, until I switch to latest tag with 13.0 version pushed.

I think the actual issue is here:

My suggestions:

-             type=edge,branch=master
+             type=edge

I guess the issue is that in the past, I have immediately merged other PRs that were queued via meta/feature-freeze after the release of a new tag, which hid the effect we are now seeing. In my opinion, we should always push :edge, right? There is no scenario in which master is updated but :edge should not.

But to me, the question remains: why didn't the default push (by merging the PR) trigger the action to build :edge?

UPDATE: Ah, now I get it:

The push on master does not change a file listed in paths:. I can provide a PR :)

Superseeded by #3662

@vincentDcmps Thank you for making us aware of this:) I have manually started a run on master, so :edge will be updated within the next half an hour and this problem should vanish.

@georglauterbach

Below is for reference, no need to read and respond 👍

Why was :edge not updated yet? :latest is equal to :13.0.0 but :edge is not..

Shouldn't matter, they would always differ in digest if this is respected:

But we've been bundling the VERSION:

They only differ after your recent change to trigger builds for :edge with VERSION since the VCS_REVISION now differs.

Regarding :edge checking for updates, I'll open a PR that doesn't run the service in :edge 👍

My suggestions:

-             type=edge,branch=master
+             type=edge

For reference, no that would be bad.

The logic here is that either the workflow was triggered by:

• A git tag for a release (create multiple image tags based on semver)
• No tag, just a push event to master branch (tags aren't associated to branches, but commits). This qualifies for :edge.

Your suggestion would publish :edge regardless of event.

• If the workflow was ever triggered to run on a different branch for example (sometimes created for PRs by maintainers, or CI scripts like CONTRIBUTORS.md updates), that'd accidentally attempt publishing a release.
• It shouldn't happen however, since we call this workflow in a controlled manner via workflow_call with explicit reference to the latest iteration of the workflow on master branch. But pushes to the master branch isn't the only trigger event, we have workflow_dispatch (manually invoked) and scheduled workflow. Best to keep safeguards in place 😅

Multiple semver tags are useful for services like watchtower to leverage, when DMS updates an existing tag these services notify, but otherwise unaware of newer tags as they don't actually understand semver (some update services do).

But to me, the question remains: why didn't the default push (by merging the PR) trigger the action to build :edge?

UPDATE: Ah, now I get it:

To be fair, it's not a change relevant to :edge to warrant building the image again and publishing it.

• It's a bug with the current behaviour for :edge, it should not check VERSION for update notifications.
• :edge users should use watchtower or configure compose (or similar) to always pull the latest :edge tag if they want to always run the current :edge.

@vincentDcmps

Below is probably not important to you anymore, but if you're interested in better identifying / understanding the actual cause of the problem, give it a read.

the issue was that I have received 5 mail by minute to inform me that update is availlable

May be something related to your configuration, you've not provided much context. :edge shouldn't behave any differently than a published release presently.

They all just check their internal copy of VERSION and do a request to compare it to the one on Github, which if found to be newer will send you one mail about the update once per UPDATE_CHECK_INTERVAL:

For example I had a very simple container running, and it received the following log when the update was checked:

$ docker run --rm -it --hostname mail.example.test --name dms mailserver/docker-mailserver

# Update check log:
$ docker exec dms cat /var/log/supervisor/update-check.log
[   INF   ]  2023-11-25 04:51:31  No update available
[   INF   ]  2023-11-26 13:51:04  Update available [ 12.1.0 --> 13.0.0 ]

# Default internal alias for local user accounts that belong to DMS hostname (`@mail.example.test`)
# Mail sent to root locally will be redirected to `postmaster@example.test`
$ docker exec dms cat /etc/aliases
root: postmaster@example.test

In the above logs, the notification mail (ID F16DF483E) is sent from root@mail.example.test (DMS hostname) to the same address which by default DMS aliases to the assumed default postmaster account (postmaster@example.test).

However that is not a valid user to deliver mail to in this case so it bounces. In this case, the bounce is sent back to the sender ( root@mail.example.test), but since that loops back to postmaster@example.test again it bounces and Postfix knows to stop at double bounce, thus it doesn't bother trying to deliver the original notification to the intended recipient again, nor the bounce to the original sender.

If your UPDATE_CHECK_INTERVAL ENV is the default value of 1d, you could provide more context, such as what the update-check.log shows (if it was actually running more frequently than expected, thus a fault of the script or supervisord), or if it was on the Postfix side (sounds more likely) with mail delivery.

It might just be that the update notification was sent to postmaster@example.test like above demonstrates, but that bounced, yet actually delivered the bounce to a root@mail.example.test account, so attempted to send the mail back to postmaster@example.test and repeated this failure?

TL;DR

• Check your UPDATE_CHECK_INTERVAL ENV is the default value of 1d
• Confirm if the script or supervisord are actually at fault: docker exec dms cat /var/log/supervisor/update-check.log
• Check docker exec dms cat /etc/aliases or related alias/ENV for the configured Postmaster account, that it actually exists. It's possible that Postfix repeatedly tried to deliver a mail due to some failure there.

The first update check is done on container start and then repeated infinite with the configured interval. If an update is found, the update-check exits (and won't be started by supervisor again). Your PR would effectively introduce notification on each interval when an update is found.
Did your container for some reason restarted frequently? That would explain your issue.