diun
diun copied to clipboard
Expand notification template to allow container names
When I receive a notification, I get the list of images which can be updated. However, I have a lot of docker-compose.yml files running, so it gets confusing which I need to update.
e.g. Now I receive something like:
[diun 4.19.0] Docker tag docker.io/library/mariadb:latest has been released
[diun 4.19.0] Docker tag docker.io/library/mariadb:latest has been released
[diun 4.19.0] Docker tag docker.io/library/mariadb:latest has been released
But it would help if I could also include the container names in the output:
[diun 4.19.0] Docker tag docker.io/library/mariadb:latest has been released for nextcloud_database_1
[diun 4.19.0] Docker tag docker.io/library/mariadb:latest has been released for fireflyiii_database_1
[diun 4.19.0] Docker tag docker.io/library/mariadb:latest has been released for photoview_db_1
@MartenBE Which version of Diun do you use?
I use 4.19.0
Hi @crazy-max, any updates for this enhancement?
Watchtower takes container name as argument to upgrade. It would be handy if we could send container name in notification to create a link, so watchtower updates the container with a single click.
I'm calling dibs on this one. I really need this :grin: - (which of my dozen stacks is this MySQL update about, again? :mag:
Okay.... need to padel back, unfortunately.
diun
currently works like this: (simplified):
- It contacts the local Docker daemon to fetch a list of all (running/stopped/exited) containers
- For each container, it tries, by various methods, to find out what image this container was built from
- If it is an image which has come from a registry, it will write the image information into a database. Note that the information from which container this image was read is not saved.
Because of point no. 3, it is unfortunately more complicated to implement this (useful) feature, than to simply add a template tag. Because, simply put, diun
doesn't have any clue which container it has got the image information from.
This is also probably due to the fact that diun doesn't only support reading current images from a Docker server running somewhere, but it can also parse Dockerfiles or simple YAML files with a list of image names to send notifications for, See the docs. And if you, for instance, only have a simple YAML file with a list of images, there is no "container name" that could be saved with it.
One option to implement this would be to add some sort of addictional information
field into the database and diun
's internal model, so that providers can provide provider-specific information (wow, what a sentence!). The Docker provider could provide the container name and ID it got the image from, the Dockerfile provider could provide the path and the line number from which it read the image, etc.
I unfortunately, currently don't have time to change that implementation. So, if anyone else wants to, go ahead!
#749 should solve this issue, let me know what you think.