Update Versions Showing as sha256 Hash Strings Only

[Teleportist]

All containers, except a very old one for InfluxDB aren't correctly displaying the current version information. Instead only showing the sha256 hash. Is there any way to correct this please?

Thanks.

[rezstje]

If you want the new build numbers to show up you cannot use the latest tag but rather should use x.x.x tag for the version and use the regex labels in order to watch for new updates. If you use latest or stable they will show up as sha256 hashes

[Teleportist]

If you want the new build numbers to show up you cannot use the latest tag but rather should use x.x.x tag for the version and use the regex labels in order to watch for new updates. If you use latest or stable they will show up as sha256 hashes

Thank you rezstje. Please explain how I can use x.x.x tag for the version and use the regex labels in order to watch for new updates. Or will this be added in an update?

[JvdMaat]

In your docker compose you'll need to specify the version you want. Like for grafana, instead of grafana:latest, you'd want to put:

    image: grafana/grafana:10.2.3

And then in the labels put:

    labels:
      - wud.tag.include=^\d+\.\d+\.\d+$$
      - wud.link.template=https://github.com/grafana/grafana/releases/tag/v$${major}.$${minor}.$${patch}
      - wud.display.icon=si:grafana

[fmartinou]

Thank you very much @rezstje and @JvdMaat for your kindly support 👍 I assume that everything is now working fine; I close the issue.

[Teleportist]

Thank you. Makes perfect sense now, as InfluxDB is the only container where I specify the image version in my docker compose.

What does the labels entry in the docker compose do here please?

So every time WUD tells me there's an update I would presumably need to edit my docker compose accordingly for each effected container? How do I establish what the current versions of my containers are?

[fmartinou]

Hi,

The labels are there to help wud findind update candidates by filtering only on acceptable tag formats (`x.y.z for instance)

Once an update is found, you have 2 solutions to update your container.

Either you manually edit you compose file:

• change the tag value from 10.2.3 to the new version
• let docker-compose upgrade it (docker compose up -d for example)

Or you setup the docker-compose trigger to automatically perform these tasks

[Teleportist]

Thank you fmartinou,

I was hoping to avoid having to manually update my docker compose after every container update, as I usually update my containers by recreating them in Portainer, So I'll have to consider this going forward.

[Headkillah]

Hi,

The labels are there to help wud findind update candidates by filtering only on acceptable tag formats (`x.y.z for instance)

Once an update is found, you have 2 solutions to update your container.

Either you manually edit you compose file:

* change the tag value from `10.2.3` to the new version

* let docker-compose upgrade it (`docker compose up -d` for example)

Or you setup the docker-compose trigger to automatically perform these tasks

@fmartinou First, BIG THX for all your work :)

But i have a question. I´m not dumb at all :D but where is the right place to put the docker-compose triggers?

Example: I have a path /opt/docker/ who i place all my docker images.

/opt/docker
=> /opt/docker/wud -> docker-compose.yaml
=> /opt/docker/netalertx -> docker-compose.yaml

I want automatically update the netalertx container. So, please explain, where i have to place the triggers like "WUD_TRIGGERDOCKERCOMPOSE{trigger_name}_FILE" so that WUD can autoupdate the netalertx image? I think, i have to place the triggers in the "/opt/docker/netalertx/docker-compose.yaml" ?

[JvdMaat]

But i have a question. I´m not dumb at all :D but where is the right place to put the docker-compose triggers?

Example: I have a path /opt/docker/ who i place all my docker images.

/opt/docker
=> /opt/docker/wud -> docker-compose.yaml
=> /opt/docker/netalertx -> docker-compose.yaml

I want automatically update the netalertx container. So, please explain, where i have to place the triggers like "WUD_TRIGGERDOCKERCOMPOSE{trigger_name}_FILE" so that WUD can autoupdate the netalertx image? I think, i have to place the triggers in the "/opt/docker/netalertx/docker-compose.yaml" ?

Do you have a separate docker-compose for each container? It would be much easier if you combine those in a single docker-compose file from a WUD management perspective. (And for your own sanity) If you point the compose trigger to the netalertx/docker-compose that should work, but it will only be able to update that container. Not any other containers. You'd have to setup multiple instances pointing to each docker-compose file to update others. The triggers should be in your wud docker-compose under environment. In the netalertx docker-compose you can only do WUD labels.

[Headkillah]

Do you have a separate docker-compose for each container? It would be much easier if you combine those in a single docker-compose file from a WUD management perspective. (And for your own sanity) If you point the compose trigger to the netalertx/docker-compose that should work, but it will only be able to update that container. Not any other containers. You'd have to setup multiple instances pointing to each docker-compose file to update others. The triggers should be in your wud docker-compose under environment. In the netalertx docker-compose you can only do WUD labels.

Yes, all of them are separated, i have around 21 docker images :) You may be right, it´s easier for wud to have all in one place, but for me it´s better to have all of them separated, because i´m using container that have much more informations in the docker-compose.

Taking my example ... If i understand all right, i have to configure the trigger in this way to let wud automatically update my specified containers:

wud => docker-compose.yaml:

services:
  wud:
    image: fmartinou/whats-up-docker
    ...
    volumes:
    - /opt/docker/wud/docker-compose.yaml:/wud/docker-compose.yaml (the part after : is right?) or is it the same before the : ??
    - /opt/docker/netalertx/docker-compose.yaml:/wud/docker-compose.yaml
   ...
   environment:
    - WUD_TRIGGER_DOCKERCOMPOSE_WUD_FILE=/opt/docker/wud/docker-compose.yaml
    - WUD_TRIGGER_DOCKERCOMPOSE_NETALERTX_FILE=/opt/docker/netalertx/docker-compose.yaml

[JvdMaat]

This is.... a way to do it. Even with a lot of information per container, doing it in a single docker-compose file makes management much easier. (And potentially enabled intra-container traffic? Not sure how smooth that works with individual compose files. Does it create a separate bridge network for each compose file?) Anyways, in your code above, both the WUD and NETALERTX files point to the same file inside your wud container. You could update it to something like this:

services:
    volumes:
    - /opt/docker/wud/docker-compose.yaml:/wud/wud-docker-compose.yaml  # (the part after : is right?) or is it the same before the : ??
    - /opt/docker/netalertx/docker-compose.yaml:/wud/netalertx-docker-compose.yaml
   ...
   environment:
    - WUD_TRIGGER_DOCKERCOMPOSE_WUD_FILE=/wud/wud-docker-compose.yaml
    - WUD_TRIGGER_DOCKERCOMPOSE_NETALERTX_FILE=/wud/netalertx-docker-compose.yaml

I think that should do the trick. (Assuming you have the other triggers all setup right). But this way the volumes section creates two separate files. And in the environment section you're pointing to the files inside the wud container. (Since it won't have access to your /opt)

[Headkillah]

@JvdMaat

Many many thx for kicking me in the right direction :) Now almost everythin works as expected. And now i understand the concept (maybe you´re right it´s better to have only 1 docker-compose.yaml 🥇)

Keep helping the community :)