What's up docker? How to keep your containers up to date

That’s what I thought, just making sure here before submitting a bug report. Thanks!

Every reboot the MQTT does not add the sensors to homeassistant/Binary_sensors/
but in WUD/Container/local/
??

That’s really weird :thinking:.
There is probably a glitch somewhere in wud.
Can you copy/paste your analysis on a new issue on the GitHub, please?

I’ll try to reproduce the error and fix it.

FYI - I manually rolled back one of those remote containers in order to force an updated notification from WUD, and the appropriate topics showed up on my MQTT broker. So WUD appears to be working correctly

Do you persist mosquito data to an external volume?
To restore topics to the last known state when the mosquito container is recreated (and not starting over with an empty state).

Hmm the only external volume my mosquitto broker uses is its conf.yaml file ?
Should I make another volume for the broker

Should I make another volume for the broker

Yes, you can bind mount mosquitto/data.
It’s the directory retaining the state of the topics.

@fmartinou do we need to tweak something when going from 5.15 to 5.16 of WUD? Because now it starts mentioning updates also for dev image versions. This was not so previously.

Example it now shows an update available for Home Assistant but the tag is : 2022.4.0.dev20220313

Because now it starts mentioning updates also for dev image versions.

I’m not aware of any change after the 5.15 which can be responsible of such a change :thinking:

Anyway, as a best practice, please specify the regex of the tags you’re expecting ('wud.tag.include=^\d+\.\d+\.\d+$$').

For example

    homeassistant:
        image: homeassistant/home-assistant:2022.3.3
        labels:
            - 'wud.tag.include=^\d+\.\d+\.\d+$$'
            - 'wud.link.template=https://github.com/home-assistant/core/releases/tag/$${major}.$${minor}.$${patch}'
            - 'wud.display.name=Home-Assistant'
            - 'wud.display.icon=mdi-home-assistant'

With that configuration, it’s perfectly working.

Sorry been swamped with other stuff… so did not check things out.
But what I can say, is that my Home Assistant instance is a supervised one installed with HA scripts. So I never added the WUD elements to the docker info.
But even so, WUD always has shown the correct info for all HA related images. Up until 5.16 that is :wink: now I get those dev tags too ( so for hassio_cli, hassio_dns, hassio_audio, etc… )

@fmartinou what a nice project, really like it. I have one feature request if possible. Sometimes I get a API request limit, which could be plausible. But if this occured then in the web interface of WUD I can still see which docker container has an update available, but in HA -through MQTT- I get the status unavailable. Isn’t it possible to not update through MQTT if this occurs?

Btw, I have changed the time of checking to once every 6 hours (4 times a day)

Hi @Caros

Isn’t it possible to not update through MQTT if this occurs?

Probably… :grin:

I need to identify first the impacts (because pushing the information when something bad occurred is also interesting).

Can you copy/paste your post as a new Github issue, please?
It will be easier to track.
Thanks!

I tested with wud 5.16, 5.15, 5.10… and for all af them, WUD is displaying the version 2022.4.0.dev20220321 as a candidate.

So your troubles are not caused by an update of WUD.

I think you were lucky until now because HA teams didn’t push dev images with semver/calver semantics.
(I have the feeling they’ve started to do so from 2022.4.0.xxx).

So to sum up:

  1. it’s totally normal that WUD displays it as a valid update candidate because semver speaking: 2022.4.0.dev20220321 is greater than 2022.3.5 (see the spec here)
  2. you can fine-tune WUD using labels to get exactly what you want (I hope you can set labels on your containers because without that you’ll still get false positive matches)

Below the working configuration you need to setup to get things working correctly

    homeassistant:
        image: homeassistant/home-assistant:2022.3.3
        labels:
            - 'wud.tag.include=^\d+\.\d+\.\d+$$' <-- That one!
1 Like

Ok thx for checking.
I will try to use this.

Hey @fmartinou another small question… your prometheus query ( Monitoring (fmartinou.github.io) ) works great. But I’m not that versed in creating dashboards.
Any pointers to convert that to a table panel in a dashboard? Somehow I cannot extract the columns.

Any pointers to convert that to a table panel in a dashboard?

You mean in Grafana?

At the end of the page, you have examples of queries and a screenshot of the configuration to set on Grafana to get a working table.

sum by(image_registry_url, image_name, image_os, image_architecture, image_tag_value, result_tag) (wud_containers)

# or if you want to display images to be updated only 
sum by(image_registry_url, image_name, image_os, image_architecture, image_tag_value, result_tag) (wud_containers{updateAvailable="true"})

Is the screenshot not enough to help you create the table?

Yeah if you run that in the grafana explore it will show a graph and a table view. If I use the same query in a newly created panel for a dashboard and set the panel in table mode, I’m not getting the columns. Only 2, first the time and second all labels smashed together.

But like I said I have no experience with dashboard creating in Grafana yet :wink:

Anyone got an example of a link template with a pre-release semver tag?

https://github.com/someowner/somerepo/releases/tag/v${major}.${minor}.${patch}.${prerelease}

comes back as

https://github.com/someowner/somerepo/releases/tag/v1.2.3.${prerelease}

tried both ${prerelease} and ${pre-release} and unfortunately ${raw} has a hash in it.

Unfortunately, link templates only support major, minor and patch placeholders.

I had a look at the code; it should be easy to expose prerelease as well.

Can you open an issue on GitHub, please?

Will do, thanks again

I’m trying to setup IOS notifications based on this, where the notification is raised when an update is available and cleared when no longer available (i.e. an update has been done).

I can do this on an individual container-by-container basis by having a Device trigger for each and every container, but that’s painful, prone to error and needs a lot of maintenance.

Anyone have a way of doing this using a template or something, that looks at all entities under the What’s Up Docker device in home assistant, and triggers if any of them changes from off to on?