3 ms·
How does not having a monorepo solve this problem? They would still need to compile and run the same code in order to run these tests between 1000 small reposit
by thurn 4y ago
How does not having a monorepo solve this problem? They would still need to compile and run the same code in order to run these tests between 1000 small repositories vs 1 large one, presumably they see a lot of value in end-to-end tests.
Is the suggestion just "an easier way to avoid this problem is to not have so many tests?"
- hiyer 4y agoIf the change is specific to a single module, and the APIs exposed to other modules don't change (which can also be enforced with unit tests), you don't need to run the tests for every single repo for every change. Of course, one may argue that one could run module-specific tests in a monorepo as well. But that's not easy to do on a per-PR basis, so you just end up running the entire CI suite for every PR.
- Psyonic 4y agothat’s not actually what happens at Uber. They use bazel for the go monorepo which can accurately determine what modules are affected by a given change and only runs those tests. They also use mostly homegrown CI tools alongside phabricator for code review, or at least they did while I was there.
- thurn 4y agoSo you'd stop running tests for all of the calling code? It sounds like you have a higher level of confidence than I do that non-API changes can never break any downstream repositories in subtle ways.
- jayd16 4y agoI would argue it's impossible to know what you really changed without the integration tests. But also, why is it any different why are changes at a repo level all that much easier to track than, say, inspecting changed files and running tests according to what changed?