Since 1.5.0-rcX no automatic container update

[flederohr]

Hi,
since i tested out the 1.5.0-rcX versions i have not seen an automatic container update being initiated.
The manual update works for me so far, but containers with updates available seems to not get updated and restarted automatically anymore.

In the following example the nginx container has a new version available since 5 days.

Has this something to do with the maturity settings (new + 7days) or is something else not working correctly?
I thought that this only applies when explicitly defined.
Should i wait 2 additional days to see if the container update is then automatically executed?

[s-b-e-n-s-o-n]

The maturity policy is doing exactly what you configured — mature mode with the default 7-day floor. Detected 5 days ago → ~2 days to go → auto-update will fire once the gate clears (assuming your docker/dockercompose trigger is set to auto and the update threshold matches).

You can confirm or change it from the container menu ("Maturity policy") — switch the mode to all if you dont want the delay, or lower the min-age days.

FYI rc.13 now renders the remaining-days blocker directly on each container row, so the countdown is visible at a glance without opening the menu.

[flederohr]

But i have not defined any dd.updatePolicy.(maturityMode|maturityMinAgeDays) label on my containers.
The default value is supposed to be all, which should allow any update.
But it seems that the update is still checking on the default value of dd.updatePolicy.maturityMinAgeDays (7).

from documentation

Label	Required	Description	Supported values	Default value when missing
dd.updatePolicy.maturityMode	⚪	Update maturity policy — all allows any update, mature blocks updates detected less than maturityMinAgeDays ago	all, mature	all
dd.updatePolicy.maturityMinAgeDays	⚪	Minimum age in days before an update is considered mature (only applies when maturityMode is mature)	integer (>=1)	7

Is there also planned to configure this maturity settings globally with a WATCHER_ env variable so i can change the behaviour of all containers?

PS.: In the 1.5 documentation the maturity lables are not mentioned any more

[s-b-e-n-s-o-n]

You're right — apologies, my first answer was wrong. I read the screenshot wrong and jumped to maturity when it can't apply to your case.

Confirmed in code (app/model/container.ts:503-526): isUpdateSuppressed only kicks in when container.updatePolicy.maturityMode === 'mature'. If you haven't set that (no label, no UI action), updatePolicy is undefined / empty and maturity never gates anything. The default isn't "mature with 7-day floor" — there is no implicit default policy at all.

Why your containers probably aren't auto-updating (v1.5-rcX): it's almost certainly one of the trigger-side gates, not maturity. In order of likelihood:

1. Threshold too restrictive. Your docker/dockercompose action trigger has threshold=major (or similar) but the pending update is minor/patch/digest. Default is all — check DD_ACTION_DOCKER_<name>_THRESHOLD.
2. auto=false on the trigger. By default auto is enabled, but if DD_ACTION_DOCKER_<name>_AUTO=false is set anywhere it silently suppresses all actions.
3. Container include/exclude filter. dd.trigger.include / dd.trigger.exclude on the container, or the corresponding trigger-side include/exclude env vars, not matching the trigger name.
4. No docker/dockercompose action trigger at all. If you only configured notification triggers (slack/smtp/etc), updates are only announced — nothing actually performs the update.
5. Agent mismatch. Rare, but if the container runs under a remote agent and the trigger runs on the controller (or vice-versa), the trigger can't reach the container.

rc.13 (cutting now — PR #319) renders the exact blocker reason on each container row, so you'll see one of threshold-not-reached / trigger-excluded / trigger-not-included / no-update-trigger-configured / agent-mismatch directly instead of having to guess. Worth waiting a day or two for that image if you want the quick answer.

On your two other points:

• Global maturity env var — doesn't exist today. The maturity policy only has per-container UI/API controls. Filing that as an enhancement would be welcome if you want to open a discussion or issue for it; the backend model already supports a fallbackDays parameter on the resolver that a DD_WATCHER_*_MATURITY_MIN_AGE_DAYS env var could plug into.
• v1.5 docs dropped dd.updatePolicy.* labels — correct, and not an accident on the docs side: dd.updatePolicy.maturityMode / dd.updatePolicy.maturityMinAgeDays as labels were never actually wired into the watcher. The v1.4 docs listing them was aspirational. Only the API-driven UI action (the "Maturity policy" menu on each row) was implemented in v1.5.0. I'll file that as a bug — either we wire the labels the v1.4 docs promised, or we correct the v1.4 snapshot to reflect what actually shipped.

Sorry again for the wrong first answer.

[flederohr]

I have updated to drydock version rc.13.
Where do i find the additional Information that you mentioned regarding the exact update blocker reason?

[s-b-e-n-s-o-n]

It shows up in the Kind column of the Containers list (next to the major/minor/patch badge). Blocked containers get a small colored pill — e.g. Below threshold (amber, filter icon), Trigger filtered (amber, cog icon), No trigger (neutral), Agent mismatch (neutral), Security blocked (red), Snoozed (amber). Hover the pill for the full reason, an action hint, and a "lifts at" date if it's time-limited. If multiple blockers are active you'll see the primary pill plus a +N count.

Card view shows it next to the "Latest" tag; list/accordion view shows it in the row's badge cluster on the right.

For the full picture, click any row to open the side panel — Overview tab → Version section has the same pills, and the full-page view (expand button on the panel) renders every active blocker as a card with the complete message text.

If a row that's not auto-updating shows no pill at all, that itself is the answer — the backend isn't computing a blocker for it, which usually means the action trigger isn't seeing the container as a target. If that's what you see, post a screenshot of one such row plus your DD_ACTION_DOCKER_* / DD_ACTION_DOCKERCOMPOSE_* env vars (redact any tokens) and I'll narrow it down.

No standalone docs page for the blocker reasons yet — added to my list.

[flederohr]

I dont see the mentioned pills
Here is a screenshot:

and here my DD_ACTION_DOCKERCOMPOSE_* env vars:

      ### Monitoring
      - DD_ACTION_DOCKERCOMPOSE_MONITORING_FILE=/drydock/monitoring/compose.yaml
      - DD_ACTION_DOCKERCOMPOSE_MONITORING_PRUNE=true
      - DD_ACTION_DOCKERCOMPOSE_MONITORING_COMPOSEFILEONCE=true
      - DD_ACTION_DOCKERCOMPOSE_MONITORING_ONCE=false
      ###

      ### MySql
      - DD_ACTION_DOCKERCOMPOSE_MYSQL_FILE=/drydock/mysql/compose.yaml
      - DD_ACTION_DOCKERCOMPOSE_MYSQL_PRUNE=true
      - DD_ACTION_DOCKERCOMPOSE_MYSQL_COMPOSEFILEONCE=true
      - DD_ACTION_DOCKERCOMPOSE_MYSQL_ONCE=false
      ###

      ### Jellyfin
      - DD_ACTION_DOCKERCOMPOSE_JELLYFIN_FILE=/drydock/jellyfin/compose.yaml
      - DD_ACTION_DOCKERCOMPOSE_JELLYFIN_PRUNE=true
      - DD_ACTION_DOCKERCOMPOSE_JELLYFIN_COMPOSEFILEONCE=true
      - DD_ACTION_DOCKERCOMPOSE_JELLYFIN_ONCE=false
      ###

      ### Calibre
      - DD_ACTION_DOCKERCOMPOSE_CALIBRE_FILE=/drydock/calibre/compose.yaml
      - DD_ACTION_DOCKERCOMPOSE_CALIBRE_PRUNE=true
      - DD_ACTION_DOCKERCOMPOSE_CALIBRE_COMPOSEFILEONCE=true
      - DD_ACTION_DOCKERCOMPOSE_CALIBRE_ONCE=false
      ###

      ### Nextcloud
      - DD_ACTION_DOCKERCOMPOSE_NEXTCLOUD_FILE=/drydock/nextcloud/compose.yaml
      - DD_ACTION_DOCKERCOMPOSE_NEXTCLOUD_PRUNE=true
      - DD_ACTION_DOCKERCOMPOSE_NEXTCLOUD_COMPOSEFILEONCE=true
      - DD_ACTION_DOCKERCOMPOSE_NEXTCLOUD_ONCE=false
      ###

The labels defined on the mysql container config are:

    labels:
      - dd.watch=true
      - dd.tag.include=^\d+\.\d+\.\d+$$
      - dd.tag.transform=(\d+\.\d+\.\d+)$$ => $$1

[s-b-e-n-s-o-n]

Two things — one bug on our side, one fix on yours.

The missing pill is a bug in rc.13 — sorry about that

The eligibility data is computed correctly on the backend, but the UI mapper (ui/src/utils/container-mapper.ts) doesn't pass the updateEligibility field through to the frontend. So the entire UpdateEligibilityBadges feature ships dead in rc.13 — list view, side panel, and full-page view all silently render nothing. Backend tests covered the computation but no integration test caught the mapper gap.

Traced your exact setup through the code: for your mysql container the backend produces eligible: false with a trigger-not-included blocker — you should be seeing an amber "Trigger filtered" pill. Fix is going into rc.14.

Why mysql isn't auto-updating

Exactly what the (fixed) pill would have said: trigger-not-included. Dockercompose action triggers default to auto=oninclude — they only fire on containers that explicitly opt in via a label. Your mysql container has no dd.action.include / dd.trigger.include label, so the MYSQL trigger never matches it.

Two ways to fix on your side — pick whichever fits your pattern:

Per-container opt-in (selective; recommended if you want different policies per container):

# mysql compose
labels:
  - dd.action.include=mysql

Apply the same to each of your other services — match the trigger name from the env var (jellyfin, calibre, nextcloud, monitoring).

Trigger-wide auto-on (fire-on-everything-matching-the-compose-file; recommended if you want every container in that file to update):

# drydock env
- DD_ACTION_DOCKERCOMPOSE_MYSQL_AUTO=all
- DD_ACTION_DOCKERCOMPOSE_JELLYFIN_AUTO=all
- DD_ACTION_DOCKERCOMPOSE_CALIBRE_AUTO=all
- DD_ACTION_DOCKERCOMPOSE_NEXTCLOUD_AUTO=all
- DD_ACTION_DOCKERCOMPOSE_MONITORING_AUTO=all

Thanks for the screenshot + env-var dump — directly surfaced a bug in the new feature that our tests didn't catch.

[flederohr]

Thank you for the help.
I updated to rc.14 and the amber Pill was now shown, also stating that the dd.action.include label is missing on my containers.
After configuration of these labels on the containers the update automatically triggered 👍

[s-b-e-n-s-o-n]

Update: this work is on the v1.6.0 line — see the roadmap table in the README ("declarative update policy (env + label + UI) with override tracking"). Three-tier precedence (env < label < UI), dd.updatePolicy.* labels for maturityMode / maturityMinAgeDays / skipTags / skipDigests, an overridden badge wherever the UI value differs from the declarative value, and a "revert to declarative" action.

(Originally tracked as issue #320, since closed — detailed scope moved to the internal roadmap rather than a public issue.)

[s-b-e-n-s-o-n]

Heads-up: based on feedback that the row pills were noisy when everything is configured correctly, the next RC moves them to off by default, with a single toggle in Settings → Appearance to turn them back on.

Your discovery path still works — opening a container's detail panel always shows the full diagnostic section ("Why isn't auto-update running?") with the same dd.action.include / trigger / agent reasons that helped you find the missing label in rc.14. The only change is that they're not shouting from every row by default.

Thanks again for the back-and-forth on this — it's what shaped the redesign.