Summary of Updates as a notification #1009
-
|
Right now, Shoutrr/Slack notifications are way too verbose at Info level. They send multiple notifications per container. It sends a notification for found new image, stopping old image, creating new image, starting new image. That is 4 alerts for a single container being updated. If I have many containers requiring updates, then the notifications end up truncated as shown below, which is very cumbersome as it is not readily evident which containers were omitted. Overall, these notifications are not particularly user friendly, even if they look nice. If you reduce the logging level, then you end up not getting notifications for which containers got updated. My FR is to create a notification level that just sends a summary of the update run (if updates were found). Ideally, in a single message, it just sends which containers were updated which is the most relevant information, though if there is space, I guess you can also include the shortform prior hash -> new hash. This would be much more useful because it would allow me to enable push notifications on these alerts, and from my phone be able to see the summary of the run in a simple message. Right now, if I enable push messages, it means I would be getting 4+ messages per run
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 12 replies
-
|
Yeah, that is what the PR that caused the issue described implemented. Or rather, support for it in the templates. It's an opt-in feature that needs --notification-report to be activated. The default template does not behave the way you describe though, but it can be accomplished with a custom template. |
Beta Was this translation helpful? Give feedback.
-
|
The indentation was for use on CLI, it doesn't line up that way in YAML. WATCHTOWER_NOTIFICATION_URL: "logger:"
WATCHTOWER_TRACE: "true"To see what the rendered template looks like in the log: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for all your help! This worked for me, and I was able to reference the new default template you are including in the latest PR to get one I was happy with that only triggered on updates. As such, the proposed default template looks pretty good except that it lists the "Fresh" containers which seems like overkill. The "legacy" notifications did not list out the containers that were already up to date. I can use my template without issue, just some food for thought in case that particular section makes sense to exclude. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, you are probably right. Thanks for testing it out! |
Beta Was this translation helpful? Give feedback.
-
|
does this still work? |
Beta Was this translation helpful? Give feedback.
-
|
It should work in |
Beta Was this translation helpful? Give feedback.
Yeah, that is what the PR that caused the issue described implemented. Or rather, support for it in the templates. It's an opt-in feature that needs --notification-report to be activated. The default template does not behave the way you describe though, but it can be accomplished with a custom template.