The explanation is that the semver specification implies to compare as numbers major,minor and patch digits only.
Everything after is compared alphabetically so -ls99 is greater than -ls102.
Linux server tags are a hell because they are far far far away from compliant semver versions.
The solution to make it work is the one you found by yourself in Edit 2; applying a transform function first to keep only the semver compliant part.
Edit: To be more clear, your tag v21.1-ls99 is parsed by wud as:
Ha ha you aren’t joking about the naming conventions! Technically got it working now but noticed a few ui bugs, example is that the link made up using the version numbers show the current numbers and not the updates (threw me through a loop or two). Will get an issue raised when I have chance.
I will ask, using the transform method, does it break the update kind, all my others show minor/major but the ones I transformed all say unknown.
Looking back at my original one, ‘v21.1-ls101‘ I parsed out the 21.1.101 and can confirm that. But ‘v21.1-ls102‘ comes up as unknown.
I wrote about how wud would parse it “by default” (I mean without any transform function).
Once your transform function set up, yeah, you’re right. It’s parsed as you mention it.
For the bugs you’ve detected, please open the related issues on Github.
I’ll do my best
Not for the moment.
The primary purpose of the tool was to notify only when updates are available.
Now it’s also possible to automatically replace a container with a newer version by using the Docker and Docker-Compose triggers.
Allowing to manually update a container is though interesting; I’ll think about the design of such a feature.
Love your work WUD is amazing for showing updates in HA.
WUD container working as expected.
Only the MQTT sensors are going unavailable at some point , and I believe they become available again when an update is available, any way to have the MQTT sensors up all the time ?
think my MQTT setting may be wrong ?
I look at them only occasionally so I have no idea when they went away tho.
The sensors are created in MQTT and I’ve restarted both the WUD docker container and HA and made sure the WUD container is up to date but for some reason the binary sensors are no longer being discovered correctly.
I haven’t experienced it.
My sensors are always available, mostly report up to date states and sometimes update available states when one of them can be updated.
I’m using an external mosquitto container without any specific configuration.
The sensors are created in MQTT and I’ve restarted both the WUD docker container and HA and made sure the WUD container is up to date but for some reason the binary sensors are no longer being discovered correctly.
Do you mean that when you’re looking at the MQTT topics, you can see the topics both for sensor discovery & for sensor values but nothing show up on Home-Assistant?
4. Pull the new versions ahead of time (version > 5.12.0)
You don’t want wud to automatically replace containers by the new ones because you want to keep the control?
This dry-run option can ben interesting for you; wud will only pull the new tag.
So when you decide to upgrade, the new image is already pulled locally and upgrading will take much less time.
This option is working for both the Docker trigger and the Docker-Compose trigger
hmm I have made a persistant volume for your docker container , and when first starting the container the sensors are present and up-to-date or update available , but after a reboot they become unavailable ?
19:12:36.909 INFO whats-up-docker: What's up Docker? is starting (version = latest)
19:12:36.910 INFO whats-up-docker/store: Load store from (/store/wud.json)
19:12:36.926 INFO whats-up-docker/prometheus: Init Prometheus module
19:12:37.106 INFO whats-up-docker/registry: Register all components of kind trigger for provider mqtt
19:12:37.684 INFO whats-up-docker/trigger.mqtt.mosquitto: Register trigger with configuration {"url":"mqtt://192.168.*.*:1883","user":"******","password":"******","hass":{"enabled":true,"prefix":"homeassistant"},"topic":"wud/container","threshold":"all","mode":"single","once":true,"simpletitle":"New ${kind} found for container ${name}","simplebody":"Container ${name} running with ${kind} ${local} can be updated to ${kind} ${remote}\n${link}","batchtitle":"${count} updates available","key":"************"}
19:12:37.824 INFO whats-up-docker/registry: No Registry configured => Init a default one (Docker Hub with default options)
19:12:38.688 INFO whats-up-docker/registry.hub: Register registry with configuration {}
19:12:38.723 INFO whats-up-docker/registry: No Watcher configured => Init a default one (Docker with default options)
19:12:40.324 INFO whats-up-docker/watcher.docker.local: Register watcher with configuration {"socket":"/var/run/docker.sock","port":2375,"cron":"0 * * * *","watchbydefault":true,"watchall":false,"watchevents":true}
19:12:40.343 INFO whats-up-docker/watcher.docker.local: Cron scheduled (0 * * * *)
19:12:40.354 INFO whats-up-docker/registry: No authentication configured => Allow anonymous access
19:12:40.381 INFO whats-up-docker/authentication.anonymous.anonymous: Register authentication with configuration {}
19:12:40.411 WARN whats-up-docker: Anonymous authentication is enabled; please make sure that the app is not exposed to unsecure networks
19:12:40.456 INFO whats-up-docker/api: API/UI exposed on port 3000
19:12:41.376 INFO whats-up-docker/watcher.docker.local: Cron started (0 * * * *)
19:12:41.412 INFO whats-up-docker/watcher.docker.local: Listening to docker events
19:12:46.744 INFO whats-up-docker/watcher.docker.local: Cron finished (21 containers watched, 0 errors, 4 available updates)
I’ve got two watchers setup, one monitoring the local docker socket, and another watching a remote stack. Everything works and I can see the updates in the Web UI and in MQTT (I can view my broker via MQTT Explorer), however the updates for the remote docker stack does not get pushed to the homeassistant topic in MQTT, so those containers do not get pushed into homeassistant. Is this expected behavior? I can submit a FR if so.
It’s not the expected behavior; all containers should be pushed to HA regardless the watcher type.
Can you please raise an issue on Github?
(and provide all related info like the configuration on WUD, the labels on the containers, the logs…)
Running everything in containers on the same host, HA, mosquitto broker and WUD and some more containers
Started most of them via docker-compose and no depends_on: are present.
mqtt explorer does
!
