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