Why not merge bb-deployments, bb-remote-execution, bb-storage, bb-browser, bb-event-service into one repo
weixiao-huang opened this issue · 3 comments
Since bazel is a great build tool for monorepo. However, this project splits services into multiple repo, which make it hard to see codes, package images and deploy.
Actually, since k8s test-infra that have multiple micro-services use bazel to build monorepo. So I wonder why not merge them into one repo? It is possible to support this?
I do wonder, what would be the advantages of having a mono-repo in our case?
It's probably too much work with potentially little payoff right now though perhaps having bb-storage and bb-remote-execution services in the same repo and separating out the REAPI libs (e.g tree digesters, CAS uploaders/downloaders etc.) into a different repo may make more sense. That way, you could have different clients to the REAPI share a common library.
Also, it sort of levels the playing field. Right now we know that bb-storage is usable as a remote repository. Simply because bb-remote-execution and bb-deployments already do that. The experience isn't 100% great. Hopefully it will improve over time. But at least it does work. This is a good property, because it allows people to create their own in-house deployments of Buildbarn (similar to bb-deployments) that depend on a upstream copy of Buildbarn components, maybe with a handful of custom patches on top.
If we merged everything in a monorepo, life would be easier for us working on the Buildbarn Open Source project, but it could be harmful to people who simply want to drag in Buildbarn components remotely. By not doing this ourselves, it's easy to mess that up.
Long story short, let's just stick to multiple repositories. It's not perfect, it's also not awful.