stack's compose file detection

[ondras]

My containers have a correctly filled label com.docker.compose.project.config_files and I have a 1:1 stack dir mapping. Dockhand is correctly showing my stacks, but does not assign their compose files -- I have to do this manually. Why? Is it not possible to treat the com.docker.compose.project.config_files value as the correct location for the compose file?

[lMysticl]

Dockhand already reads com.docker.compose.project.working_dir and com.docker.compose.project.config_files, but currently exposes them only through the /api/stacks/path-hints endpoint. The UI does not consume that endpoint to assign the file automatically.

Blindly adopting the label would be unsafe in the general case: it contains the path seen by the Compose client, which may not exist inside the Dockhand container or on a remote environment, and config_files may contain multiple comma-separated files. With your 1:1 mapping, manual assignment is the current behavior. Automatic assignment would need a UI path that validates accessibility and handles multiple Compose files; the container labels themselves are fine.

[ondras]

Thanks for the prompt response! I have a working setup with tens of stacks and would like to switch from an old-school CLI approach to Dockhand. Having the stack compose files adopted automatically would save me a lot of time -- especially because I have a 1:1 mapping and my config_files is always a single-value. And I would say that such setup is rather mainstream: the 1:1 mapping is recommended anyway and multi-value config_files is trivially detectable/ignorable. So perhaps a configuration option "trust config_files" (off by default) would make some sense?

[lMysticl]

Yes — an explicit opt-in such as Trust Compose path labels, disabled by default, would address the portability concern without making the common 1:1 setup tedious.

I would scope it per Docker environment and auto-adopt only when:

• config_files contains exactly one path;
• that path resolves inside a configured/mounted stack root;
• the file exists and is readable by Dockhand;
• there is no existing manual assignment.

Otherwise Dockhand should keep the stack unassigned and show why the hint was rejected. The existing path-hints endpoint already provides the label data, so this is mainly validation plus UI wiring rather than a change to stack detection. Manual assignments should always take precedence.

[ondras]

Okay, shall I try to implement this and send a PR?

[ondras]

Alternatively, this can be implemented as a one-shot "auto-adopt" button, available either per-environment, or per-stack. Using the button would result in one adoption attempt (would need to satisfy the constraints given above). Perhaps this would be a less drastic change to the codebase?

[ondras]

Sent a PR for the lightweight approach: #1617