Different triggers for different containers

[Error404-Debugger]

I just came here to ask a quick question I couldn't find an answer to in the documentation: How do I define different behaviours when a new image is found based on the affected image / container?

For example: When a new version of the image container_a uses is found I want it updated immediately if, on the other hand, an updated version of container_b's image is found, I want to get an e-mail notification.

How would I go about doing that in the docker-compose?

[fmartinou]

Hi @Error404-Debugger, at this time this is not possible but it's an interesting improvement => I put it on my todo list

The closest feature that's currently implemented is to set thresholds on triggers, for example:

• auto update for all patch/minor updated (WUD_TRIGGER_DOCKERCOMPOSE_LOCAL_THRESHOLD=minor)
• email notification regardless of the update kind (major, minor, patch...) (WUD_TRIGGER_SMTP_GMAIL_THRESHOLD=all)

(please find the related documentation here)

[jebabin]

Hello,

I was looking for the same feature and ended up here. I may try to submit a pull request if I have time someday, what do you think would be the best:

• having a label like wud.trigger.exclude=WUDTRIGGER{{triggertype}}}{trigger_name} and delimit multiple trigger with "," to exclude multiple trigger
• having labels like wud.trigger.exclude.{{trigger_type}}}.{trigger_name}=1
• something else ?

To do something "better" may be we sould also have .include labels and a WUDTRIGGER{{triggertype}}}{trigger_name}_ENABLE env value, so that we could choose to have the trigger off by default and enable it only on some containers

I'm not familiar with the source code but it seems we could add a check in the init function of app/triggers/providers/Trigger.js so that the registration doesn't happen if the container should be excluded

[KeithB]

I had been wondering about something similar - probably more at a grouping level rather than per container though.

For example, being able to use labels to allocate containers across say 3 groups. My thought process tends to run on service criticality but ultimately a number of groups allows the user to choose how they treat them - group 1 could just be "things that always need updating ASAP for security reasons".

Once you have the groups, you could combine across versions to give different behaviours - say group 1 always applies patches but notifies for everything else, group 2 only ever notifies and group 3 just applies the update no matter how big a jump it is.

[philosowaffle]

+1 I think this feature is the only thing stopping me from migrating to this project from WatchTower.

[xiNeRoar]

is this implement already?

[Jarikk]

I am looking forward to having such a feature implemented too! In my case, I really want to have several groups of containers that use different triggers. For example, Home Assistant containers trigger MQTT notifications, but all the other containers, which are not related to the Home Assistant installation, run a different Telegram trigger. Something like this:

version: '3'

services:

    # Homeassistant
    homeassistant:
        image: homeassistant/home-assistant:2021.7.1
        labels:
            - 'wud.tag.include=^([0-9]\d*)\.([0-9]\d*)\.([0-9]\d*)$$'
            - 'wud.tag.triggers=MQTT_HOMEASSISTANT'                             <== this is a new Label
            or
            - 'wud.tag.triggers=MQTT_HOMEASSISTANT,TELEGRAM_ALL' 

    # Homeassistant_db
    homeassistant_db:
        image: mariadb:10.6.2
        labels:
            - 'wud.tag.include=^([0-9]\d*)\.([0-9]\d*)\.([0-9]\d*)$$'
            - 'wud.tag.triggers=MQTT_HOMEASSISTANT,TELEGRAM_ALL'

    # Nextcloud
    nextcloud:
        image: nextcloud:22.0.0
        labels:
            - 'wud.tag.include=^([0-9]\d*)\.([0-9]\d*)\.([0-9]\d*)$$'
            - 'wud.tag.triggers=TELEGRAM_ALL'

    # Nextcloud_db
    nextcloud_db:
        image: mariadb:10.5.9
        labels:
            - 'wud.tag.include=^([0-9]\d*)\.([0-9]\d*)\.([0-9]\d*)$$'
            - 'wud.tag.triggers=TELEGRAM_ALL'

    # Whatsupdocker
    whatsupdocker:
        image: fmartinou/whats-up-docker:5.1.0
        environment:
            - WUD_TRIGGER_MQTT_HOMEASSISTANT_URL=mqtt://mosquitto:1883
            - WUD_TRIGGER_MQTT_HOMEASSISTANT_ENABLED=true
            - WUD_TRIGGER_TELEGRAM_ALL_BOTTOKEN=123
            - WUD_TRIGGER_TELEGRAM_ALL_CHATID=123
        labels:
            - 'wud.tag.include=^([0-9]\d*)\.([0-9]\d*)\.([0-9]\d*)$$'

Containers without the new Label should behave as before - use all configured triggers.

[outlying]

This would be a very welcome change. In my case, I have a container whose creator automatically releases a new image version at least once a day, currently version is like x.x.2345. I'm not interested in daily updates for this container, but I do see the value in being able to receive notifications about major/minor/patch updates with settings per container, or as suggested, per group of containers - instead of only being able to set it per trigger.