Feature request: separate action trigger policy for automatic, manual, and blocked updates

[IARI]

Context

I am looking at the current deprecation notice for manual updates bypassing dd.action.include / dd.action.exclude:

• https://github.com/CodesWhat/drydock/blob/main/DEPRECATIONS.md#manual-updates-bypass-ddactioninclude--ddactionexclude-and-legacy-ddtriggerinclude--ddtriggerexclude

I also found the related prior discussions/issues:

• What are: "Trigger Filtered" and "Agent Mismatch" in rc.14? #325
• Auto trigger execution only for specific containers #160
• Restarting drydock is triggering updates of some containers #213
• Regression: Container Updates get stuck on "updating" #317

As I understand it, in v1.5.x trigger-not-included / trigger-excluded are soft blockers: they suppress automatic action execution, but manual updates are still allowed with a warning/confirmation. The deprecation page says that in v1.7.0 these will become hard blockers: the UI locks the update button and the API rejects manual updates when the action trigger is filtered by labels.

That direction makes sense to me, but I would like to request a slightly more expressive policy model for action triggers.

The use case

I want some actions to be unavailable ("hard blocked") by default for most containers, and for selected containers, I want to allow the action explicitly with labels.

I have both:

1. 3-4 stacks that are directly managed by docker compose, and
2. others that are managed through portainer.

So for example Docker Compose / stack update actions should only manually be included for the 3-4 directly managed compose stacks - and unavbailable for the bulk of portainer-managed stacks.

But “allow this action” and “auto-run this action” are different decisions.

For example, for a Docker Compose action trigger I may want:

• default: hard-blocked / not available for containers
• specific labels: allow this action manually for selected containers
• separate labels: allow automatic execution for less critical containers

The matrix I am hoping for

Ideally, for each action trigger, there would be a way to express the default behavior and then override it per container:

State	Meaning
blocked	action is not shown/allowed for this container; API rejects it
manual	action can be run manually from UI/API, but does not auto-run
auto	action can run automatically when an update is detected

Then labels could opt a container into one of these states for a specific action trigger.

Pseudo-example, not necessarily proposed syntax:

# drydock trigger config
DD_ACTION_DOCKERCOMPOSE_COMPOSE_DEFAULT=blocked

# container A: manual only
labels:
  dd.action.allow: dockercompose.compose

# container B: automatic
labels:
  dd.action.auto: dockercompose.compose

# container C: remains hard-blocked by default

Or, if this fits the existing include/exclude model better, maybe something like:

DD_ACTION_DOCKERCOMPOSE_COMPOSE_AUTO=manual-oninclude

where included containers are manual-allowed, not automatically updated, and a separate label/config enables automatic execution.

Why AUTO=oninclude does not fully cover it

AUTO=oninclude is close, but it seems to conflate two concepts:

1. This trigger is allowed to handle the container.
2. This trigger should auto-run for the container.

After the v1.7.0 hard-blocker change, AUTO=oninclude sounds like it will provide:

• not included -> hard-blocked
• included -> allowed and eligible for automatic execution

What I am missing is:

• not included -> hard-blocked
• included -> allowed for manual execution only
• explicitly auto-enabled -> automatic execution

Questions

1. Is this already possible with the current/planned v1.7.0 model and I am just missing the intended configuration?
2. If not, would the project be open to separating “action allowed” from “action auto-runs” for Docker/Docker Compose/Command triggers?
3. Would it make sense to model this as a per-action default policy plus per-container labels, rather than overloading AUTO?

Thanks for all the work on the update eligibility model. The hard-blocker direction is exactly the kind of safety boundary I want for powerful action triggers; I would just love to have a manual-only allowlisted state as well.

[scttbnsn]

@IARI Thanks for laying this out so clearly — your reading of the current and planned behavior is correct, and this is a real gap rather than a duplicate of #160.

I traced it against the current v1.6 implementation:

• AUTO=none disables automatic dispatch, but without an include label it still leaves the compatible action available manually.
• AUTO=oninclude uses the same include decision for access and automation, so adding the label grants both manual and automatic execution.
• The v1.6 global notify | manual | auto mode is intentionally an installation-wide safety ceiling; it cannot make only a smaller subset of containers automatic.

That means Drydock cannot currently express your full matrix: blocked by default → manually allowlisted → smaller automatic subset.

I've accepted this into the v1.7 roadmap as 6.0.1 Per-Action Access and Automatic-Execution Policy. It is now an explicit prerequisite for the planned change that promotes trigger-not-included and trigger-excluded to hard blockers. We will not ship that hard-block flip by itself and remove the current manual-only escape hatch.

The implementation contract recorded in the roadmap is:

1. Resolve one blocked | manual | auto state per action trigger and container.
2. Keep the global mode as an upper bound — a per-action policy may be more restrictive, never less restrictive.
3. Separate action authorization from automatic promotion. A distinct label such as dd.action.auto is the leading candidate, but we will fix the exact env/label syntax in the phase specification before implementation rather than overload AUTO again.
4. Use the same resolver for Update Status, UI button state, manual API admission, and automatic simple/batch/digest dispatch.
5. Make selection policy-aware when multiple Docker/Docker Compose actions are compatible, instead of selecting the first compatible trigger and only then applying its labels.
6. Cover Docker, Docker Compose, and Command actions with an explicit backward-compatible migration for existing AUTO=all|oninclude|none / boolean configurations.

This stays out of the v1.6 cut because that branch is in release convergence, but it is now scheduled in the correct v1.7 policy/taxonomy lane and this discussion will remain open as the design reference. Thanks again — the Portainer/direct-Compose split is exactly the concrete case that shows why access and automation need separate controls.

[IARI]

Thank you for responding so quickly and positively - I'm happy that you plan to incorporate it.

So if I understand correctly,

• 1.6 will be released soon
• the point 2. (global mode = upper bound) prevents the full matrix
• in 1.7 it the full matrix might become possible?

And thanks again, that you have created this fork/rebrand of WUD - it seems super promising and I'd be glad to.
Let me know, if I can support in any way

[scttbnsn]

Yes — with one correction to the middle point:

• v1.6 is in release convergence now. We are working through the final review and release gates, so I do not want to promise an exact date before those clear.
• The global mode does not eliminate the full matrix; it is the installation-wide safety ceiling. With global auto, the v1.7 per-action resolver can still choose blocked, manual, or auto for each container/trigger. With global manual, a per-action auto result is capped to manual. With global notify, Drydock-managed action execution remains disabled. A local label therefore cannot weaken the administrator-wide setting.
• The full per-action matrix is planned for v1.7, not merely a maybe. The exact environment-variable/label syntax and migration details still need to be specified before implementation.

The most useful support right now would be a couple of real configuration examples: ideally one direct Compose stack and one Portainer-managed stack, showing which Docker/Compose/Command actions should be hidden, manually available, or automatic. Those would make excellent acceptance fixtures. Testing the eventual v1.7 prerelease against that mixed setup would also be especially valuable.

I will tag this discussion when the specification and implementation are ready for feedback. And thank you for the kind words — I am glad Drydock looks promising for your setup.