Is there a way to check for updates when a container isn't using :latest tag?

[ovizii]

Say I have mission-critical containers, not this one, just an example but here you go: image: ghcr.io/mealie-recipes/mealie:v2.7.1

Could it be possible to get a notification about an update? So I know there is one available and can manually update?

[mag37]

You mean if there's an update with a new tag - like in your example of running :v2.7.1 tag and there's a :2.7.2 tag released?

Sadly not - I'm not really comparing/checking different tags but just "locked" in the current tag used by the image. The current way of checking for updates is just comparing the hash, assuming that if the hash in the registry is different than the one locally, it's an update. Not comparing versions.

[ovizii]

That is what I meant. Unfortunate, but I guess I'll take what I can get :-)
I have a daily check with another tool running for updates to those containers on their GitHub release page, just thought if one tool could do the job of two :-)

[mag37]

Yeah sadly that's the current stage.
I've been looking at tags a few times and it's a mess :D So I rather not incorporate that currently.

[eichhorn]

@ovizii Which tool you‘re using currently to check updates for new tags? Searching for something similar.

[ovizii]

@ovizii Which tool you‘re using currently to check updates for new tags? Searching for something similar.

I'm using changedetection.io you can self-host it or simply use a hosted version. It checks the github project page for releases.

[vorezal]

What's Up Docker? (WUD) is a very customizable tool that allows you to control version checking and automatic updating of images based on semver. I got it mostly set up myself and then promptly removed it because it was just too complex and heavy for my use case. You might also be able to use Diun and set it to watch all tags in a repo to see whenever updates are made to any tag, which was more than I needed as well. Then I came here 😄

[yoyoma2]

What if a file stored the hash when a notification is sent. An option could disable repeated notifications about the same new hash. Each notification would be about a new version you haven't heard about yet so you can investigate. I still like repeated notifications as a reminder so single notifications should be optional.

[mag37]

I think you're talking about something else now @yoyoma2 - tied to the other discussion?
Or do you mean this is related to checking tags?

[yoyoma2]

The scenario is as @ovizii said "mission-critical containers" that "have a daily check" but updates are performed elsewhere than dockcheck.sh. Since it's mission-critical most new versions will be ignored after investigation unless a significant fix or an essential new feature is introduced. Even desirable versions will be ignored for a waiting period before upgrading to assess stability. This results in repeated daily (or more) notifications about the same new available version.

Say a file .hash_ghcr.io_mealie-recipes stored the hash of the latest online version when a notification was sent and no repeated notifications would be sent until a different hash was detected by dockcheck.sh.

TLDR: mission-critical containers are almost always behind latest and a way to avoid repeated notifications for those specific containers would be nice.

[mag37]

Ah yes - thank you for the clarification.

Well yes it's a good idea and I agree it might be irritating having the same container spam you every day that it got a new update. That issue has a few different approaches to get around (I'll come back to that).

This discussion - if I understand it correctly - is rather about containers being on a specific version tag like the example given ghcr.io/mealie-recipes/mealie:v2.7.1.
That means it wont notify you if there's a v2.7.2 released. And working with checking/comparing tags is quite a mess.

Some people suggest that you set a less specific version-tag to receive the minor releases and then manually do the major steps.
Like in this case, you could set :v2.7 or even :v2 depending on your assessment. And it should wildcard and update to the minor new versions.
But there's no way for dockcheck to currently check any other way than the compose definition.

And to address a spammy notification. If there's a container you always hold, there's probably a few different ways to get around this. Example:

• Add it to be excluded in your main scheduled check.
  • dockcheck.sh -ine important_container
• Run another scheduled job where it targets that specific container and set a days old threshold
  • dockcheck.sh -ind 10 important_container
    Or create a wrapper-function/script to run dockcheck with a few different checks with different settings.

As always - I'm grateful for your ideas and input :)
I just want to avoid jumping through hoops and twisting code too much if it's avoidable.

[yoyoma2]

I realized yesterday when clarifying my scenario that I had skimmed through the OP too quickly 4 days ago and my comment was off topic. Sorry...

The -d option will reduce spam but if for mission-critical containers I may actually run a dockcheck more than daily to know/investigate sooner about possible critical security fixes but usually won't install for days.

I totally understand that not all fringe cases can be handled. Just throwing ideas out there. Still love this tool!

The github documentation (not the script) about options has a trailing double quote typo: Options:" <----

[mag37]

No worries :)

I'll keep your idea in the back of my head - wont act on it currently though. I'll add it as a consider this to my long list!

Thank you! Patched in the upcoming branch.

[ovizii]

Oh, and here's another related question that popped up. The reason I am using dockcheck is because I can delay updates, i.e. only get updates older than 7 days. Now I realized that some projects do daily builds which means, I will never get an update as with very frequent updates they will never reach the age of 7 days.

Totally different issue but I thought I'd throw it in here.

[mag37]

Oh. Hadn't thought about that conflict, interesting.

Though those two interests are hard to combine, what would your ideal case be?

I mean if using eg :latest on something that's rebuilt daily and then try to delay updatea X days contradict itself somewhat.

[ovizii]

Though those two interests are hard to combine, what would your ideal case be?

I mean if using eg :latest on something that's rebuilt daily and then try to delay updatea X days contradict itself somewhat.

That is easy. On images which are not that important, and I am willing to risk a breaking change, I set them to :latest, but I would still love to delay its update for 7 days, thus giving time for any issues to be found and fixed before I get that 7 day old version.

i.e. a few days ago a friend asked me if I also had the same issue with adguard home and nope, I did not as he was immediately updated via watchtower while I had a 7-day buffer. By the time the fix is out I get it 7 days later. Works for me.

The other use cases are:
A) the image is known for not breaking easily and I trust its maintainer. It is also well-thought-out with its versioning scheme. i.e. traefik:v3 - I am happy to keep updating it with every image older than 7 days as long as its within the v3 version and not a major upgrade.
B) the image is known for breaking changes, so I set it to a fixed version like :v2.7.1 and have another tool like changedetection.io notify me of new releases which I manually upgrade to after reading the changelogs.

[mag37]

Ah yes I see your usecase / issue.

In your example with adguard I clearly see the reasoning behind delaying updates until it've been a "stable" release for X days.
Though I dont know how to work around images having new builds nightly/daily..

Well, if you got a clear suggestion on what kind of use / options you're missing or looking for I'd gladly explore possibilities in the future!

[ovizii]

I have no ideas or suggestions, I simply thought I'd mention all cases in case someone else has an idea. For now, some containers simply have to be monitored by changedetection and manually upgraded.

Feel free to close this discussion, I simply wanted to add my input :-)

[mag37]

I'm happy that you do, all input is appreciated!

And indeed, others might have ideas or thoughts so I'll rather leave it open.

[yoyoma2]

With the hash files idea above, in addition to ensuring the hash has changed before notifying again, there could also be a MinHoursBetweenNotifications variable (default set to zero is disabled) based on the age of the hash file. Even if running dockcheck every 4 hours, with MinHoursBetweenNotifications=168 you would go a week between repeated notifications for any container.