Configuring repositories manually is fine for small deployments and monorepos. But I expect many midsized (and up) customers will have many, many repositories they want to host in the bundle server. Often such repositories will be created outside the control – and even the view – of the administration. Having the bundle server autodiscover new repositories and decide whether to replicate them will be key to making this a suitable option for those customers.
We learned with the GitHub Enterprise Server repo cache that customers often think in terms of organizations and locations. For example, they wanted to express policy like:
"Repositories in the contoso/ org should always replicate to every geography."
"Repositories in the fabrikam/ org must never replicate to this specific cache node."†
Notably, the policies and tools for implementing them will necessarily be specific to a vendor's setup. While many public forges use an $ORG/$REPO hierarchy, that's not universal or required. Repository discovery isn't possible with Git alone, so calling (e.g.) vendor REST APIs will likely be required. As with the Git Credential Manager, we should find a way to build a vendor-neutral core engine upon which experts can implement vendor-specific modules.
†This gets complicated with forks. contoso/foo could be forked to fabrikam/foo, leading to a contradiction. That's why we opted not to support such a policy in the repo cache, but that has proven to be unpopular. While I don't think we should change the repo cache's behavior now, I'm not keen to repeat this mistake in a fresh take on the scenario. ↩
Configuring repositories manually is fine for small deployments and monorepos. But I expect many midsized (and up) customers will have many, many repositories they want to host in the bundle server. Often such repositories will be created outside the control – and even the view – of the administration. Having the bundle server autodiscover new repositories and decide whether to replicate them will be key to making this a suitable option for those customers.
We learned with the GitHub Enterprise Server repo cache that customers often think in terms of organizations and locations. For example, they wanted to express policy like:
contoso/org should always replicate to every geography."fabrikam/org must never replicate to this specific cache node."†Notably, the policies and tools for implementing them will necessarily be specific to a vendor's setup. While many public forges use an
$ORG/$REPOhierarchy, that's not universal or required. Repository discovery isn't possible with Git alone, so calling (e.g.) vendor REST APIs will likely be required. As with the Git Credential Manager, we should find a way to build a vendor-neutral core engine upon which experts can implement vendor-specific modules.†This gets complicated with forks.
contoso/foocould be forked tofabrikam/foo, leading to a contradiction. That's why we opted not to support such a policy in the repo cache, but that has proven to be unpopular. While I don't think we should change the repo cache's behavior now, I'm not keen to repeat this mistake in a fresh take on the scenario. ↩