[PATCH] git: move non-kallithea hooks and execute other hooks

[Lance Edgar]

I'm fairly new to Kallithea but also encountered this problem with my 
setup.  I'm not clear where things are at with this discussion now, but 
it seems unresolved so wanted to share my perspective.

I need the same thing others have mentioned:  to effectively have 
multiple post-receive hooks for certain git repos.  Possible solutions 
appear to be:

A) Kallithea hook gets built-in support for running additional hooks, 
discovered by globbing

B) admin must create a Kallithea extension which somehow does that same 
thing

C) admin installs custom hook script which can run the Kallithea hook, 
plus additional (per glob)

Thus far I've gone with option C, because option A doesn't exist and 
option B seems wrong to me.  The only thing I don't really like about C 
is that Kallithea will no longer update its own hook script.  If I'm 
being honest I think option A should exist and if so I'd use it.


On 11/4/20 3:14 AM, Tim Ooms wrote:
> On 24/10/2020 13:05, Mads Kiilerich wrote:
>> On 10/23/20 9:30 AM, Tim Ooms wrote:
>>>> It might have rough edges to bypass Kallithea when accessing 
>>>> Kallithea-managed repos. It is perhaps better to go with the 
>>>> assumption that Kallithea fully owns the repositories it manage.
>>>
>>> I tried to not bypass Kallithea by letting it execute the other 
>>> hooks. I know the mercurial hooks are more integrated, but as the 
>>> git hooks don't work the same way I think this is the next best 
>>> thing. Although there may be better ways, I'm not sure.
>>
>>
>> If you only access the repos through Kallithea, I think it would be 
>> better to run your hooks as Kallithea extensions. I'm not sure that's 
>> possible right now, but we can perhaps fix that.


It seems to me that the patch submitted by Tim Ooms will solve for 
option A.  The argument here appears to be that keeping things "inside" 
of Kallithea is the ideal goal, but in my mind that's exactly what the 
patch does.

I think most folks who encounter this problem, will already have a 
script which is perfectly suitable for use as post-receive hook. Their 
problem is how to get Kallithea to invoke it.  Trying to shoehorn their 
existing script into a Kallithea extension seems like overkill.

So what Kallithea needs is some way to invoke these scripts, and the 
patch does that fine AFAICT.  Kallithea has no reason to assume that any 
extra hook scripts will work properly etc. but I don't think that is 
enough to "void the warranty" in general, it should just run them in 
good faith.  Presumably the admin installed them so consequences will 
fall to that person.


>>> Can you say more about your use case? What other hooks are 
>>> installed? What precautions do they use to avoid clobbering the 
>>> Kallithea hooks?
>>>
>>> Use cases I think of:
>>> post:
>>> * trigger CI build (like jenkins)
>>> * notify bug tracker (like the bug genie)
>>> pre:
>>> * check for commit message
>>> * verify syntax/codestyle
>>> Other examples: 
>>> https://scriptrunner.adaptavist.com/stash/3.0.14-beta1/docs/pre_receive_hooks/ 
>>>
>>> These hooks are really independent and don't touch the repository. 
>>> If they fail, it has no effect on the other hooks. A hook can mess 
>>> up if it just hangs and does not return. But you will always have 
>>> this if people are using custom hooks, even in mercurial.
>>
>>
>> Thanks. Some good examples of "hooks" into the default process.
>>
>> I understand you install these hooks yourself - it is not some 3rd 
>> party system doing it. Your purpose with installing the hooks is to 
>> customize the Kallithea process.
>>
>> In that case, would it perhaps be better to hook into Kallithea 
>> "extensions" instead of hooking in as Git hooks? If we don't have the 
>> right kind of extension hooks, perhaps we should introduce that?
>
> If installing an extension is as easy as installing the git hook 
> (meaning: simply put the provided hook code somewhere) this can indeed 
> be a good solution (together with something to allow custom hooks).


My guess is that the use cases above apply to nearly all who encounter 
this problem.  And although can't be sure, I would expect this to be a 
somewhat common problem.  (Anyone who is moving to Kallithea but already 
had hooks in their previous git repos...)

If Kallithea has built-in support then it potentially removes a lot of 
frustration.  Not clear to me why requiring each admin to make an 
extension is the "better" way if it is a common problem.


>>> It must be a general challenge with Git to fit multiple hooks into 
>>> the single hook slot. Is there any prior art for solving / working 
>>> around that problem?
>>>
>>> Yes, there is:
>>> * solution using "pee": 
>>> https://git.seveas.net/using-multiple-post-receive-hooks.html
>>
>>
>> Nice. But depends on perl. It would be nice to have it as Python. But 
>> I guess Git already depends on perl ...
>>
>>
>>> * using bash built-ins: 
>>> https://serverfault.com/questions/909153/how-to-add-multiple-post-receive-hooks-to-a-git-repository 
>>>
>>
>>
>> It seems like the hooks can have multiple lines on stdin. This batch 
>> script will invoke the hooks multiple times in that case. That might 
>> be unfortunate. And it also doesn't detect failures.
>>
>> And unfortunately, it seems like they both just describe how it *can* 
>> be done. It is not a standard way of doing it.


I was also surprised at first, to find that this problem even existed.  
Why doesn't git support multiple post-receive hooks natively?  I think I 
understand more now, why they would want to just stay out of that game.  
Sort of unfortunate that Kallithea must bear the brunt of that decision 
here.


>>>> It would be nice if there was a "standard" dispatcher (perhaps a 
>>>> simple shell script) that could be installed in The Hook Location - 
>>>> something that picked up multiple hook files. Instead of having our 
>>>> hook call others, it would perhaps be better to install a 
>>>> generic-ish hook and let it dispatch to both our hook and the 
>>>> existing one.
>>>
>>> I would indeed like a shell solution (I used the bash solution till 
>>> now, but till now that causes problems when doing an update), but 
>>> that ain't portable and I think Kallithea can run on Windows. It can 
>>> have advantages to let Kallithea run the other hooks: they can be 
>>> managed (in a later stage) by Kallithea, can be logged by Kallithea 
>>> and admins can be notified if a hook fails to run.
>>> Also, running directly the Kallithea hook, Kallithea -being the one 
>>> managing the repository- is sure that its hook is correctly called 
>>> and it's shebang is correctly set and executable.
>>>
>>> This can also be done using something generic-ish (and I like the 
>>> idea), but you add another layer that can fail and another file to 
>>> keep up to date like the existing hook.
>>
>>
>> As a step in the right direction, we can perhaps let Kallithea 
>> create/overwrite post-receive.d/kallithea.hook *if* post-receive 
>> already exists *and* isn't a kallithea hook, *and* if post-receive.d 
>> exists.
>>
>> That will leave it to you to install the dispatcher when installing 
>> your hooks.
>
> This would indeed be a step in the right direction. The admin can 
> always search in the docs how to create the dispatcher if she/he wants 
> to keep a single custom hook.
> The globbing with pre-&postfix or the subdirectory (cleaner, but can 
> break the script) both have there (dis)advantages.


+1 for this.  If option C is used (as it is for me) then currently 
Kallithea will not update its own script because I've moved it.  So 
would love to see this land even if option A does too.

Thanks for reading!

Lance