Hi there. I am in the process of building some POCs and working with a group of devs here to possibly roll out garden to the wider community of devs at my company. Basically our front-end and back-end devs have a set of services that need to be rolled out in order for them to to work on any given application. We currently use a fairly complicated and error-prone system of docker-compose files and/or a set of remote services in kubernetes to make local dev possible. I have built a number of garden demos on my machine to demo (Macbook, osx 12.5.1) , and they work great – but unfortunately, however, we run into weird issues when other devs attempt to use the same demos.
Basically we have a project with a bunch of remote sources for around 25 or so services set up in our project module. These deploy as expected. However, the trouble starts when a dev clones down the front-end projct repo in the garden project root.
Garden seems to be unable to pick up the garden.yml file in the cloned repo on the next deploy. On my machine, the cloned project works fine, on other developers machines it does not. One dev was able to fix the problem by adding the project as a submodule. This has not worked for other developers.
Note that we all run pretty much the same hardware, and the project and modules are identical. It is possible our git versions are not exactly the same – I am checking today. We have run deploys with -l silly to no avail – there is no mention of the cloned project in the logs at all – it is as if it is invisible to garden.
I assume what is going on is that rather than doing a simple eumeration of the filesystem as expected, to find garden.yml files in subdirectories, garden is somehow relying on git, but I am unclear on how (or for that matter why) it does this.
So I guess I am left wondering if garden is really only suitable for monorepos? Or am I just missing something obvious? Do you have any best-practices for polyrepos that I should be aware of? Thanks in advance!
EDIT: We are all using garden 0.12.44.
Ok – so I think I have a handle on this. The failures we were seeing were related to the git repo layout this user was using. The garden project root was one level below the repository root. This broke garden submodule discovery because the .gitmodules file was placed at the repository root (this is normal git behavior). But the garden project definition was one level below that – so garden deploy never saw the submoduled repositories. Why it works on one machine without submodules, but requires submodules on another machine remains a mystery. With that said, I have a suggestion and a question:
First, this all really needs documentation badly. You probably need a section under ‘Using Garden’ pretty near the beginning for polyrepo users that explains the need for submodules and has an example somewhere. I haven’t seen anything that explains this (maybe I missed it), and the submodule business was kind of a lucky guess on my part, although I’ve since seen maybe one forum post that mentions it.
Secondly, I guess I am wondering why the repository layout is critical at all for finding garden.yml files. It seems like an odd design choice. Can anyone provide a quick summary of why things are done this way?
Again – thanks in advance