Monorepo benefits maybe a small set of developers that manages it for the whole company, at the cost of most other engineers who develop in it. Unnecessary waste of time.
Case in point another new merge queue has to be created to somehow manage the messiness
We have a monorepo at work and the CI only runs a minority of tests prior to merging, and then reverts bad commits later. It can take a few hours until every test has run including your commit. I don't know enough about the setup to know how it decides to run what tests though
Monorepo benefits maybe a small set of developers that manages it for the whole company, at the cost of most other engineers who develop in it. Unnecessary waste of time.
Case in point another new merge queue has to be created to somehow manage the messiness
So they reinvented OpenStack's Zuul?
I've always thought if you're pushing changes at the sort of velocity that requires it, you're doing something wrong, anyway.
In my experience, it's a monorepo problem.
We have a monorepo at work and the CI only runs a minority of tests prior to merging, and then reverts bad commits later. It can take a few hours until every test has run including your commit. I don't know enough about the setup to know how it decides to run what tests though