Repository cache for GHES

[github-product-roadmap]

Summary

Many GitHub Enterprise Server customers have teams and CI farms located all around the world. The GitHub repository cache will mirror repositories near these clients, reducing latency and bandwidth required to support geographically-distributed teams while also reducing load on the primary instance.

Intended Outcome

Massive read load from very large CI farms can affect performance on the customer's GitHub Enterprise Server. This degrades the developer experience - fetches, pushes, merges, and even non-Git features can be slowed down when load is high. Also, there's no reason to transmit the same Git data over and over again via a long-haul network link. The repository cache helps customers reduce bandwidth consumed on long, possibly intercontinental networks. It also helps customers serve their CI and automation needs from a dedicated host, reducing the load on the primary GHES and improving the experience for users of the primary.

How will it work?

The repository cache listens to the primary instance (whether that's a single GHES server, a geo-replicated set of instances, or a cluster configuration) for changes to Git data. CI farms and other read-heavy consumers clone and fetch from the cache server instead of the primary instance. Changes are propagated across the network once per cache instance rather than once per client.