UI thinks an update is available even on same hash

[utdrmac]

(using getwud/wud:main) I have WUD_TRIGGER_DOCKER_LION_AUTO=false set. I see in the UI, an update is available for docker-resolver container:

The 'triggers' tab shows me irrelevant other triggers. my docker-resolver container is not a compose.yml; just a normal docker. So why am I seeing compose triggers, telegram trigger, openhab compose, etc?

I click the 'Docker Lion' Run button and watch WUD logs. I see it download the latest image for docker-resolver, stop the old container, and launch a new one with the updated image.

However, the UI still believes an update is available. Even after refresh browser, the UI still shows an update. Clicking the telegram trigger also says an update is available.

$ psdocker | grep resolv
c3a1d52d93ef   dvdarias/docker-hoster:latest           12 minutes ago   Up 12 minutes             docker-resolver
foo@lion:~$
foo@lion:~$ docker inspect docker-resolver | grep Image
        "Image": "sha256:c51629bd3874cfc9d14e4703223af09aa33a8c87d33cacb5540c3361fbdc526f",

This screenshot confirms that container c3a1d5 is detected by WUD (after container restart), and we can see above that is correct. We can also see the current image hash of the running container matches the "latest" hash, but WUD still thinks it's updateable.

[fmartinou]

The 'triggers' tab shows me irrelevant other triggers. my docker-resolver container is not a compose.yml; just a normal docker. So why am I seeing compose triggers, telegram trigger, openhab compose, etc?

By default, triggers are associated to all discovered containers unless you set labels on the container to explicitly include or exclude triggers (example).

You can share your wud conf and the labels you set on your discovered containers so I can confirm my assumption.