Skip to main content
In a giant repository like Google, there is no snapshot of version control where everything is green. (google3 doesn’t even have parse-able Starlark code at a given “commit”). However, there is a lot of extra machinery needed to deal with different teams selecting some “view” over the monorepo that they care about, compute the status for that view, prevent code changes that break it, and determine what is safe to ship. Moreover, if each team has a different status, then each team needs their own “build cop” which is a drain on them, and if they aren’t diligent then existing redness also impacts shared library authors when they trigger that pipeline. The best answer is to keep it simple: the entire repository is green, or it’s not. A single BuildCop can maintain this state across a large repository, provided that you’re quick to revert breakages. Have a policy that makes it clear that the revert happens without judgement, and the roll-forward follows the normal process.
Read more: monorepo shared green