That’s a great question. The notion of sub-projects has been on our roadmap for quite awhile now but we haven’t found time to action it. We’re also debating the design, it’s a complex feature and a lot to consider.
That being said, there are workarounds but I think I’d need to understand your use case a little bit better before suggesting one.
First off, does the sub-project directory have a project level Garden config file? I.e. a config file that has
kind: Project. Because Garden should always find the “nearest” project config and deploy the services that belong it. And not anything higher in the tree. So it sounds like the sub project is missing a config with
Second, are those sub-projects a logical group of modules that have the same runtime environment (i.e. the all run in the same Kubernetes cluster) or is there more to it? In that case, you might be able to achieve what you’re after with some templating hacks, e.g. by leaning on the the
disabled field in the module config.
And if there’s anything else you can share about the structure of these sub-projects and your use case, then that would be super helpful.