3 ms·

> Trying to build CI on every branch before merging to master just won't work with the scale they are dealing with. Google does it with 50 times the developer

> Trying to build CI on every branch before merging to master just won't work with the scale they are dealing with. Google does it with 50 times the developer count. > At 1000 developers, the rate of PRs coming in makes it impossible to determine what current master will be when the PR is ready to merge (i.e. when the branch has a green build). True, it is impossible to catch all errors like this, but you can catch almost every error by building and testing it against current master and then merge it with the master 20 minutes later when the build is done. I have seen maybe one build breakage a year being introduced due to this in projects I've worked on, so it isn't a big deal.

greiskul 7y ago
> building and testing it against current master and then merge it with the master 20 minutes later when the build is done. And I'm pretty sure that is the way Google does it too. Test a commit against current master, if tests are green commit. Then run tests against master again (and I think this stage might not run for every single commit) to see if anything broke on the rare times there was an actual conflict. If that run was red, which should be rare, then you can have the system do a bisect to find the offending commit, or just run all the ones that haven't been individually tested.
iamweswilson 7y ago
For even better accuracy you can use a tool that will run tests against speculative merge states. Zuul[1] is an open source project that supports it out of the box. [1] https://zuul-ci.org/docs/zuul/user/gating.html https://zuul-ci.org/docs/zuul/user/gating.html
randomidiot666 7y ago
You have no idea how Google solved it. Basically everyone with a Monorepo (except Google) implements it as a cargo cult best practice. Mindlessly copying Google without understanding how Google actually does it.
- deleted 7y ago
  [deleted]
- randomidiot666 7y ago
  To the clowns downvoting my comment: to even suggest that Google does a full automated regression test on the entire codebase on every merge is beyond stupidity. Having a single Git repository with full regression test on every merge is a primitive naive interpretation of how actually Google does it. Their solution is very different and very custom built.

greiskul 7y ago

> building and testing it against current master and then merge it with the master 20 minutes later when the build is done. And I'm pretty sure that is the way Google does it too. Test a commit against current master, if tests are green commit. Then run tests against master again (and I think this stage might not run for every single commit) to see if anything broke on the rare times there was an actual conflict. If that run was red, which should be rare, then you can have the system do a bisect to find the offending commit, or just run all the ones that haven't been individually tested.

iamweswilson 7y ago

For even better accuracy you can use a tool that will run tests against speculative merge states. Zuul[1] is an open source project that supports it out of the box. [1] https://zuul-ci.org/docs/zuul/user/gating.html https://zuul-ci.org/docs/zuul/user/gating.html

randomidiot666 7y ago

You have no idea how Google solved it. Basically everyone with a Monorepo (except Google) implements it as a cargo cult best practice. Mindlessly copying Google without understanding how Google actually does it.

deleted 7y ago
[deleted]
randomidiot666 7y ago
To the clowns downvoting my comment: to even suggest that Google does a full automated regression test on the entire codebase on every merge is beyond stupidity. Having a single Git repository with full regression test on every merge is a primitive naive interpretation of how actually Google does it. Their solution is very different and very custom built.