On Thu, Apr 30, 2020 at 11:33:27PM +0800, Jiang Xin wrote: > Thanks to Peff for providing technical details of the architecture. I > understand that "receive-pack" of GitHub backend is not involved in > references update (executing the commands), so the "proc-receive" hook > won't be turned on for GitHub's architecture. While in our > architecture (inspired by "spokes" of GitHub), the proxy will deliver > not only packfile, but also commands to all three replicas. The proxy > will execute "receive-pack" on the replica with a special argument, so > the proxy can talk with "receive-pack" with an extended protocol. > After running pre-receive hook and release the packfile from > quarantine, the replica will stop and wait for the proxy to > coordinate. After creating a distributed lock, the proxy will tell all > the replicas continue to update the references. One problem we met is > the proc-receive and the post-receive hook must be executed once. We > can make the execution of the hooks idempotent, or let only one of the > replica run the hook. We choose the latter. OK, that makes more sense. We solve that by not updating the refs at all via receive-pack (which gives us flexibility to run our own hooks separately on just one replica, etc). > I agree that adding new capability (report-status-v2) is a better > solution, but I think the above extension is a bit wordy. We add > additional 18 characters for each "ok <ref>" status, and add > additional 32 characters for each "ng <ref> <msg>" status. Can we > extend it like this: > > ok <ref> > [optional key-value pairs] > ng <ref> <error message> > [optional key-value pairs] I doubt the number of bytes is all that important, but certainly I'm happy with this (and it looks like what you put into v14). -Peff
