Get the versions of updated containers/apps (old and new) during notifications

[fede843]

Is your feature request related to a problem? Please describe.

It would be nice than in notifications we could see which is the current (running) container or app version and the new version replacing it.

As it is I really cannot tell if the update represents a minor or major update for instance. If I could see that, maybe for a major update I would spend some time and check logs, etc.

Describe the solution you'd like

To have 2 fields available for templates, one for each version. The problem here is that there is no global generic way to find this. It would be ideal if containers maintainers could just use a unified docker label to post this info. But that would never be the case. So, instead we could define a command to exec into the running container before and after the update.

For instance for an NIGNX container I could just define this label:

version_check_command: "nginx -version"

That command will be remotely (docker exec) run before and after update, and those values will be available for template.

This simple approach let the user to define based in each case a programmatic way to get useful info.

Describe alternatives you've considered

Currently, I just occasionally go and manually check what are the current versions, and from memory compare the most important ones. Also I am subscribed to some GitHub repos, and when a new release is issued, I get notified.

Additional context

No response

[piksel]

On the note of alternatives:

There is an attempt to standardize the metadata in container labels called OpenContainers metadata labels, and support for adding them to the notifications are in PR: #1729. Unfortunately, this relies on the authors adding those labels to their images (which nginx for example, doesn't).

We could combine the two into a property .Version that is populated in the following order:

1. If present, run the version_check_command (though the label needs proper namespacing of course) and use that value as the version.
2. If present, use the image's org.opencontainers.image.version label value.
3. Use the image hash as the fallback.

[fede843]

Hi, yes, that sounds better approach. And yes, I was aware of that label, but as we said, depends on the publisher. In the positive side, big groups like linuxserver are using it. Nevertheless the custom command completes the circle.