Hey guys! I been using Garden for a couple of months now and I have a couple of questions about repositories structures and what's the best practice to handle them with Garden. Context: Company-A has 100 repositories with different kind of services (apis, frontends, workers, AI,etc). As this would be too much of a load for Engineers local computers to handle bootstrapping all the repositories with a single

garden deploy

is not a feasible option. Another option that can be used is that for example; imagine we are developing

service-a

and this service need some other services to work: - service-b - service-c - frontend In this case I would run

garden deploy

in

service-a

folder and that will reuse the other services using repositoryUrl's as modules, this will allow engineers to only deploy in their local computers the related services they are working on. Is this approach recommended? Is there any examples of a case like this? Question 2: Is there a way to make that garden works using a folder within the code repository? For example; if we create a folder called

garden-config

and store

garden.yaml, project.garden.yml, modules.yml, garden.env

in there it would be possible to run garden-deploy from that folder but use the files one level above? Does garden has a hard requirement to be at the same level of the dockerfile? Thanks a lot ❤️

Hi ShankyJS and thank you for being one of our most active community members. As I am going on vacation from tomorrow and this is a big process question I am going to ask @swift-garage-61180 to take a look 👀

Thanks a lot @quaint-dress-831 and @swift-garage-61180 ❤️

Hi @bright-policeman-43626 Regarding the first part: The recommended approach is indeed to use remote sources and create a "parent project" that picks the modules needed. The parent project wouldn't need to have any modules of its own. Just project config with a [

sources

field](/Users/eysi/code/garden-io/garden/bin/garden). You can conceptually have multiple parent projects that pull in different modules as needed. And we have quite a few plans for better supporting these kind of workflows, but no fixed timeline. And for the second part: The Garden config can be "above" the Dockerfile and/or other source files but not "below" it (file hierarchy-wise)". So this will work:

console
├── api
│   ├── dockerfile
│   └── src
├── api.garden.yml
└── project.garden.yml

But not the other way around. It's definitely something we'd like to support but will take a bit of effort to implement.

In my case; any microservice it's a project, because those microservices require different microservices to work together in a local-dev environment, so what I do is; if I'm working mainly with

service-a

, I use service-a-project and use sources to require the other microservices as dependencies. Not sure if that's recommended?

That definitely works as well. But yeah, we'll be making quite a few improvements to better support these kind of workflows in the medium term. I'd actually be keen to get your thoughts and feedback once we start working on it if you wouldn't mind sharing. Sounds like you have exactly the kind of set up we have in mind.

What's the best way to share my thoughts about how I think this can work? I already have some microservices running in some local environments using this approach and I think it's kind of great! And also have some ideas about how to improve stuff as well!

@bright-policeman-43626 I've DM'd you with next steps!

Answered! Thanks a lot @quaint-dress-831