On Wed, Feb 10, 2016 at 01:24:16AM +0000, Robin H. Johnson wrote: > I will happily take a pre-receive hook, regardless of it using > pkgcore/portage. Note that it should operate WITHOUT having a checkout, > needs to be able to take new ebuilds & Manifest on stdin. > > Trying to checkout the tree for each update I don't think is a good > idea, as it's 5+ seconds of overhead; and somebody else could try to > push a change in the meantime. Slight clarification here: I am willing to keep a stateful checkout as a post-receive hook, and the pre-receive hook CAN use that checkout to read other contents. It just might be more than one commit behind sometimes.
Eg: T=1 push P1 comes in, triggers pre-receive, passes, triggers post-receive hook (async) T=1..5 working tree in the process of post-receive, state is dirty [1] T=2 push P2 comes in, triggers pre-receive. What should happen? What should the pre-receive do in this case? A) fail outright? (terrible choice, included for completeness) B) block on the active post-receive completing? (while !done; sleep) C) validate against a changing tree? (might fail, not in a way that's easy to reproduce) D) validate against a previous CLEAN tree? (if this push depends on a change in push P1, it will fail when it should have passed) [1] actually a really good question here, does git prepare changes somewhere in .git and atomically rename into place, even so, multiple moves cannot be atomic together. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee E-Mail : [email protected] GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
