Problem
With many entrypoint DAGs in one installation, a flat dagsDir is hard to keep organized in the repository (review, ownership, grouping related workflows on disk).
Today Dagu only lists YAML files in the top level of dagsDir. Nested files do not appear in Definitions (or the list API), even though they can still be invoked via dag.run with a path.
We use workspaces/labels for filtering in the UI — that helps navigation, but it is not a substitute for filesystem structure in the repo.
This looks intentional after #887 / #950 (“do not read DAGs in sub-directories”), which fixed duplicate entries by excluding subdirs entirely.
Proposal
- Discover DAGs recursively under dagsDir (optionally behind a config flag to preserve current behavior).
- Ensure a unique id per DAG across the tree (e.g. path-relative name, or require unique name: and fail on conflict).
Related
#887, #950
Problem
With many entrypoint DAGs in one installation, a flat dagsDir is hard to keep organized in the repository (review, ownership, grouping related workflows on disk).
Today Dagu only lists YAML files in the top level of dagsDir. Nested files do not appear in Definitions (or the list API), even though they can still be invoked via dag.run with a path.
We use workspaces/labels for filtering in the UI — that helps navigation, but it is not a substitute for filesystem structure in the repo.
This looks intentional after #887 / #950 (“do not read DAGs in sub-directories”), which fixed duplicate entries by excluding subdirs entirely.
Proposal
Related
#887, #950