[Feature request] Option to send notification on every check, showing state

[Timmiej93]

I want to display the state of my containers (update available / not available) in HomeAssistant. Currently, diun only provides a notification for when an update is required. When the container has been updated, this does not get notified to the end user.

Current behavior:

• At scheduled moment, sends notification only when update is available

Desired behavior:"

• At scheduled moment, send a notification of every watched container that has an attribute "update available", with a value of true or false

Since not everybody may want this, an option to enable/disable this behavior would probably be a good idea.

[crazy-max]

@Timmiej93

At scheduled moment, send a notification of every watched container that has an attribute "update available", with a value of true or false

It defeats the purpose of Diun which sends notifications when an image update is available. Maybe we could extend the notify_on opt with the unchange attribute but I don't really agree with doing that. Can you give me your workflow and a detail use case to get a better idea of what you expect?

[Timmiej93]

It defeats the purpose of Diun which sends notifications when an image update is available.

I don't see how adding the option to also send a notification for images that don't have an update available would change this. Sure, for those that use something like Telegram, this option probably isn't for them, but as long as there's a setting that toggles this behavior, it doesn't change anything for those people. I think a great option would be to have a setting that switches between how diun currently works (only sending a notification when an update is available, and only for that specific image), and a sort of "regular overview mode", where a notification is sent every time diun checks if there are updates available. This would then be 1 JSON array or object, containing the JSON object of every container/image that is being watched, with an extra attribute, something like update_available: true/false.

Maybe we could extend the notify_on opt with the unchange attribute but I don't really agree with doing that.

I'm not sure what the unchange attribute does, I assume that would trigger when an image goes from "update available" back to "up to date"? What does the unchange attribute currently do?

What I'm trying to achieve is a list in Home Assistant that shows me the state of my containers: "Update available" or "Up to date". That means that there's a state visible in HA. Switching to "Update available" isn't hard, I set up a webhook that diun calls, which changes the state to "Update available". However, there's not really a way for HA to know if the update was ever executed, so it'll always stay on "Update available".

I thought of the option of resetting the state to "Up to date" every X hours after the last "update available"-message, (where X is the same period you use in diun), so basically right before the next notification from diun would come in, but that's nowhere near as polished as it could be.

Like I said: I get that you don't want to fundamentally change diun. There's probably a lot of people who like that they get a message that tells them a container needs an update once, and only once. I do however think that it would be nice to also have the option to just get an update every X hours that just gives you a list of all watched containers that shows you which have an update available and which don't. It isn't taking away anything from the other users, it's only adding to it.

[crazy-max]

What does the unchange attribute currently do?

This means there is no update available for the image that has been scanned which seems what you want. For a webhook notif, the payload would look like this:

{
  "diun_version": "4.0.0",
  "hostname": "myserver",
  "status": "unchange",
  "provider": "file",
  "image": "docker.io/crazymax/diun:latest",
  "hub_link": "https://hub.docker.com/r/crazymax/diun",
  "mime_type": "application/vnd.docker.distribution.manifest.list.v2+json",
  "digest": "sha256:216e3ae7de4ca8b553eb11ef7abda00651e79e537e85c46108284e5e91673e01",
  "created": "2020-03-26T12:23:56Z",
  "platform": "linux/amd64"
}

• skip means the image has not been scanned (filtered out by a include/exclude rule)
• error well that's pretty obvious :)

[Timmiej93]

So I'm guessing that all 5 statuses here are accepted arguments for diun.notify_on here? If so, this feature request would turn into a bug report for the documentation ;). It would probably be a good idea to have all accepted options listed in a table like this one.

[crazy-max]

That was just an example. Only new and update are available atm.

[Timmiej93]

So the states exist, they're just not functional? If so, why do the other states exist, especially since you mentioned you don't agree with adding unchange (which I don't quite understand, more options/customizability is always good, right?)?

[crazy-max]

Sure we can add the unchange state to the notify_on opt. I'm fine with it.

[dsm1212]

The other case I've seen where I would prefer this behavior is when notifications fail. I've had two cases:

1. Sometimes I've had diun mail messages throttled by google. When I miss a message, I'm not informed about an update till the next update. Of course, if diun logs a message error it could skip recording the change too.
2. I switched my network to ipv6 and I don't know why but google would not process mail requests from diun. I created a new api key and then they started working, but I had to go through the image list and try to figure out what I missed because restarting diun I lost the error log messages. I run the diun check once per week because I'm not interested in daily maintenance so I'm totally fine with a full statement every run.

[dsm1212]

Oh, wait, maybe I need a different feature request. Reading this carefully I think the OP asked to include the unchanged items, but that doesn't necessarily mean you will tell me again about what changed that has not yet been updated. I can see really three useful modes: incremental - as it works today, full - report on everything that is out of date, exhaustive - include unchanged.