This is WAY WAY more on the topic of monobuilds from having been deep into this at twitter.
- If you are a core library developer, you need a MUCH crazier build system that can kick OFF MANY remote builds at the same time. local just won’t suffice if you are a local dev
- If you are service developer in a department with a ‘few’ libraries just for your department, you need a local runMonoBuild.sh that detects file changes -> maps file changes to projects(gradle should do this!!!) -> maps projects changed to projects need to build/validate -> build all projects locally
IN ALL CASES, there is a step of mapping projects changed to projects that depend on that project. For this, imagine a repo where you end up with 3000 directories. you DO NOT WANT to scan the whole repo to see who depends on library X. Instead, library X in a composite build ‘should’ be required (only if some gradle setting is set) to declare ‘who’ depends on him (and the library that depends on him perhaps does the same. While this is a bit of extra work for the developer, it does 2 things
- high performance on traversing who depends on library X directly or indirectly as in library X -> library Y -> service B is known right away
- CRITICAL -> now companies have a way of slowing down just anyone depending on my teams library so that we can discuss or refer to the library they should use. People reach in all the time and this is not good
- VERY VERY well documented who depends on my library in my mono-repo
I want to get gradle to a point where it ‘could’ replace the twitter mono-repo build system but it is not quite there yet.