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

[Lance Edgar]

Thanks for the update.


On 1/11/21 7:53 AM, Mads Kiilerich wrote:
> As next step, I propose the changes in 
> https://kallithea-scm.org/repos/kallithea/pull-request/306/_/hooks .
>
> Some of it took a slightly different direction than Tim proposed. And 
> cleaning up many other related things. Please let us know if you 
> disagree with any of it.


The only thing I spotted in the above PR was this bit where you would 
remove any existing pre-receive hook.  Seems to me that the admin may 
well need to install pre-receive for their own needs and you should 
never delete it even when "force overwrite" is requested?  Or maybe I 
read it wrong.

https://kallithea-scm.org/repos/kallithea-incoming/changeset/e7acbdb8fd8ce7d520ce216b5baeb42a72dc7fdd#kallitheamodelscmpy_n717


> Finally, with these things out of the way, the core problem of 
> custom/multiple Git hooks is more clear.
>
> The way Kallithea use Git, I see no alternative to Kallithea 
> installing the post-receive hook to be able to detect what has been 
> pushed. (But it is possible we could come of with another scheme, and 
> thus completely avoid this problem?)


Agreed, I see no reason not to use git hooks for Kallithea's own needs.


> I don't like the idea of Kallithea having its own custom way of 
> allowing admins to install hooks. If admins want to install extra 
> hooks, they should do it in a "standard" way. Tim mentioned a couple 
> of examples of how it could be done, but nothing that was ready for 
> use, covered relevant concerns such as having a scheme that didn't 
> pick up backup files or non-executable files, with a convincing cross 
> platform story (covering Windows), or approximated a "standard".
>
> I think the best (and preferred) way forward for having custom and 
> multiple hooks for Git would be to have a "standard" dispatcher that 
> can be installed in hooks/HOOKNAME . That hook should be a separate 
> project, independent of Kallithea, and with a fair chance of being 
> used widely, also when not using Kallithea. Ideally, it should be 
> upstreamed in Git.
>
> The scheme could be that it runs all executable 
> hooks/HOOKNAME.d/*.hook (or some other scheme, such as 
> hooks/HOOKNAME.*.hook). It should have some meaningful handling of 
> stdin, stdout, exit code, and how they should be shared/chained when 
> multiple hooks run and might fail. And it should support both Linux, 
> Mac, and Windows (where there might be cmd/exe/whatever extensions and 
> no exe flag).
>
> When there is a good 3rd party solution to the problem, I will 
> implement support for it in Kallithea: detect if a hook from that 
> project is installed in hooks/HOOKNAME, and then write the Kallithea 
> hook to something like hooks/HOOKNAME.d/kallithea.hook instead.
>
> I suggest you team up to create that project. We will support you, but 
> Kallithea would not be a good owner of it.
>
> Does that make sense?


All that does make sense.  However I would like to propose yet another 
way of looking at it.

We have been discussing "multiple post-receive hooks" but in reality 
there need only ever be 2:  Kallithea's own "internal" hook script (in 
use today), and "some other" script as defined by admin.

Git after all will only support one script out of the box, so any admin 
who needs "multiple" things to happen in a hook, normally must write one 
script which contains several steps.  So then "all extra" steps needed 
beyond Kallithea could be represented as a single script.  If the 
admin's needs are complex then maybe that script for them must have the 
"meaningful handling of stdin" etc. which you mentioned.  (Perhaps with 
auto-discovery, like example at https://serverfault.com/a/909154 .)  But 
there would be no true need for the "dispatcher" to have those smarts - 
it need only a) run the Kallithea hook, and then b) run the "other" hook 
script if present.  (I guess, it *would* still need to correctly pass 
stdin at least.)

I agree that a smarter dispatcher might be a nice gift to the Git world, 
beyond Kallithea.  But I think it is not strictly necessary here.

I was curious about what GitLab did for this.  IIUC their Server Hooks 
doc (https://docs.gitlab.com/ee/administration/server_hooks.html) 
basically reduces the problem in the same way.  They allow the admin to 
create a `custom_hooks` folder in the repo, and in it they can place a 
(single!) `post-receive` script for example. Presumably the "true" hook 
script from Git's perspective, is the one provided by GitLab itself, but 
as an optional last step it can fire off whatever is in 
`custom_hooks/post-receive` if present.

So ultimately I agree that "Kallithea having its own custom way of 
allowing admins to install hooks" is not 100% ideal, but that "they 
should do it in a standard way" seems to me still possible and pretty 
low-hanging fruit, without adding in a 3rd party dispatcher.  (Although 
by "standard" I am only referring to the "Kallithea standard way" 
here.)  We need only define/document a single custom hook script/path 
which the admin must define, *should* they even need to bother.

If some day Git is given native multi-hook support then obviously should 
revisit.  But I suspect their approach will never change since end user 
can always make a wrapper script, e.g. also 
https://stackoverflow.com/a/30104427

Lance