<aside> 🌍 This page is public. Read about our take on public when possible, private when necessary.
</aside>
Currently, Gitpod is built around some key product assumptions:
This idea works great for single repo projects (mono-repos with multiple components in it or monoliths), but is not straight-forward with projects that consist of multiple git repositories.
That said, there are currently two main solutions for allowing Gitpod to work well for multi-repo set-ups.
🅰️ Multiple Workspaces
Depending on how many repositories a project consists of and how the components communicate with each other the preferred solution is to, configure each repository individually and then start workspaces for the needed repositories and bridge the network.
Example: A project consists of two repositories: "Backend" and "Frontend". Each repository has its own .gitpod.yml. The backend repository doesn't even have a dependency on frontend code, so people can code on it without starting a workspace for Frontend if they wish. If you work on both, you start two workspaces one for "Frontend" and one for "Backend" and just code on them through two distinct IDE windows as devs would do locally. The network bridging makes sure your Frontend workspace uses the services exposed by the "Backend" workspace.
Drawback: If you have a large number of small services, starting a large number of workspaces and maintaining the automatic workspace timeout is inconvenient.
Benefits: This approach nicely keeps your repositories separated including their configuration (no big single dev env image but a small dedicated one per repo). Also, it allows starting workspaces on repository contexts for all your components.
🅱️ Meta Repository
Introducing one main meta-repository that contains the configuration for a single large dev environment that clones all the repos. The information of what sub repos to clone can be done through git submodules or any of the many other existing solutions.
This kind of mimics a mono-repo and if possible I'd go down the mono-repo route instead of this, because the drawbacks mentioned below:
Drawback: Starting a dev environment from the sub repositories doesn't work, because they don't have a configuration (you can add links to the Readme, though). Contexts don't work, i.e. starting a dev environment on a branch or PR. Therefore also prebuilds are not triggered from pushes in sub-repositories.
Benefits: Kind of is the same as local, where you have one machine that is containing all the dependencies for the various components. More convenient than individual workspaces when you have a highly distributed application with lots of small services sitting in individual repositories.