env. WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG isn't working anymore since 1.4.0

[MilesTEG1]

Describe the bug
Since the update to 1.4.0, the environment variable WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG isn't working.
In my docker-compose.yml file, I set this : - WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG=[ Watchtower-DS920+ ]
But all email I received has this subject:
Watchtower updates on 5d11f1abc714

Before the update, I got :

To Reproduce

Expected behavior
It should be with the subject I declare in the env variables, like this not too old email:

Screenshots
See previous...

Environment

• Platform = Synology NAS DS920+
• Architecture = amd64 (CPU = Intel Celeron J4125)
• Docker version = 20.10.3, build b455053

I use Portainer CE 2.11 to create my container

Logs from running watchtower with the --debug option

I'm not sure how to do the --debug option... But here what I have: ```log time="2022-01-25T09:56:09+01:00" level=debug time="2022-01-25T09:56:09+01:00" level=debug msg="Sleeping for a second to ensure the docker api client has been properly initialized." time="2022-01-25T09:56:10+01:00" level=debug msg="Making sure everything is sane before starting" time="2022-01-25T09:56:10+01:00" level=debug msg="Retrieving running containers" time="2022-01-25T09:56:10+01:00" level=debug msg="There are no additional watchtower containers" time="2022-01-25T09:56:10+01:00" level=debug msg="Watchtower HTTP API skipped." time="2022-01-25T09:56:10+01:00" level=info msg="Watchtower 1.4.0" time="2022-01-25T09:56:10+01:00" level=info msg="Using notifications: smtp" time="2022-01-25T09:56:10+01:00" level=info msg="Only checking containers using enable label" time="2022-01-25T09:56:10+01:00" level=info msg="Scheduling first run: 2022-01-26 05:00:00 +0100 CET" time="2022-01-25T09:56:10+01:00" level=info msg="Note that the first check will be performed in 19 hours, 3 minutes, 49 seconds" ```

Additional context

[bodycount28]

+1.

I too noticed this and have the same problem since the upgrade.

[sashaoshurkov]

+1
Looking forward to fixes please :)

[dgkovachev]

same here...

[a-gerhard]

+1

[danielmbrown603]

+1

[ijaron]

+1

[dgkovachev]

+100 this feature is very much needed when you have more than 5 servers. Hope this can be resolved shortly!

[nilava]

+1

[jan-di]

Please don't write +1 comments, add your thumb up on the opening post. Otherwise you send an notification email to everyone that follows this issue..

As a workaround I changed the hostname of the container. The email header results in "Watchtower updates on ", which is not perfect but make the email distinguishable. CHanging the hostname of the watchtower container shouldn't have side effects.

[dgkovachev]

I personally went with the WATCHTOWER_NOTIFICATIONS_HOSTNAME=xyz variable witch achieves the same result as described above. Hope this helps...

[dvuckovic]

Note that in order to even consider WATCHTOWER_NOTIFICATIONS_HOSTNAME value, WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG must not be set in the first place.

[EDIflyer]

This still doesn't seem to work for me? I tried the original WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG as per the documentation but no luck, then tried WATCHTOWER_TITLE_TAG as per #1270 above but neither seemed to do anything. I then set WATCHTOWER_NOTIFICATIONS_HOSTNAME instead and that worked OK, although is a different feature (but at least proves changing the environment settings was doing something!)

[piksel]

@EDIflyer It's merged but not released in stable. You can test it in containrrr/watchtower:latest-dev.

[EDIflyer]

Ahh OK, sorry hadn't spotted it hadn't made it to stable yet 😄 👍

[EDIflyer]

@piksel just to confirm now tried :latest-dev and confirm WATCHTOWER_NOTIFICATION_TITLE_TAG and WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG both worked as alternative options along with WATCHTOWER_NOTIFICATIONS_HOSTNAME as a combined option 👍 🎉

[BeyondVertical]

I have the same problem and wanted to ask when it is released to the stable branch?