Ensure dockercompose trigger creation uses existing dd/wud.compose.file labels only

[Copilot]

This PR keeps compose trigger creation aligned with the existing label contract and removes the metadata-based fallback that expanded scope beyond the requested fix.

• Compose trigger source

  • Trigger auto-creation remains based on:
    • dd.compose.file
    • wud.compose.file
  • No additional Docker Compose metadata labels are used for trigger creation.

• Scope correction from feedback

  • Removed the previously added fallback logic based on:
    • com.docker.compose.project.config_files
    • com.docker.compose.project.working_dir
  • Removed the metadata-specific regression test that validated that fallback behavior.

• Current behavior

  • Containers create dockercompose triggers when the existing compose file labels are set.
  • Per-container compose options (backup, prune, dryrun, auto, threshold) continue to be passed from dd/wud.compose.* labels as before.
  • Fixed a cached-container edge case in the Docker watcher where compose-labeled containers could return early from store and skip trigger creation; watcher now avoids cache short-circuit when a compose label exists but no compose trigger is cached yet.

• Additional regression coverage

  • Added a focused Docker watcher unit test for the cached-container path to verify compose trigger creation and triggerInclude population when dd.compose.file is set.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Crow-Control]

@copilot im not asking for adding extra metadata config, i want the current labels to correctly create triggers.

[Copilot]

@copilot im not asking for adding extra metadata config, i want the current labels to correctly create triggers.

Done — I removed the compose metadata fallback and kept trigger creation scoped to the existing dd.compose.file / wud.compose.file labels only. This is in commit c2a68e4.

[Crow-Control]

@copilot somehow the containerlabels dont create the trigger in the ui?

[Copilot]

@copilot somehow the containerlabels dont create the trigger in the ui?

Fixed — the issue was cached containers returning early before compose trigger creation. I updated the watcher to still create the trigger when dd.compose.file / wud.compose.file is present but no compose trigger is cached yet. Included a focused test for this path in commit b90f120.

[Copilot]

Pull request overview

Aligns Docker compose trigger auto-creation strictly to the existing dd.compose.file / wud.compose.file label contract, while fixing an edge case where cached containers could skip compose trigger creation due to an early store short-circuit.

Changes:

• Prevent early return from addImageDetailsToContainer when a compose file label exists but no compose trigger is cached for that container.
• Reuse composeFilePath computed up-front for trigger creation.
• Add a unit test covering the cached-container path to ensure compose trigger creation and triggerInclude population.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
app/watchers/providers/docker/Docker.ts	Adjusts store short-circuit logic to allow compose trigger creation when needed based on dd/wud.compose.file.
app/watchers/providers/docker/Docker.test.ts	Adds regression test ensuring cached containers with dd.compose.file still create compose triggers and set triggerInclude.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

With this change, if dd/wud.compose.file is set but dockercompose trigger creation fails (exception in ensureDockercomposeTriggerForContainer), composeTriggersByContainer[containerId] remains unset. That means needsComposeTriggerCreation will stay true on every subsequent poll, so the watcher will repeatedly skip the store short-circuit and re-run the full image inspect path just to retry trigger creation, which can add ongoing load/log noise. Consider handling the “container already in store + needs trigger creation” case without inspecting the image (create trigger, update composeTriggersByContainer, and return/update the stored container’s triggerInclude), or add a backoff/sentinel to avoid repeated inspect work on persistent failures.

Suggested change

	if (
	containerInStore !== undefined &&
	containerInStore.error === undefined &&
	!needsComposeTriggerCreation
	) {
	if (containerInStore !== undefined && containerInStore.error === undefined) {