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

[Mads Kiilerich]

On 1/11/21 10:16 PM, Lance Edgar wrote:
>
> 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 
>


Right, thanks. I propose 
https://kallithea-scm.org/repos/kallithea-incoming/changeset/9522b915c913#kallitheamodelscmpy_n674 
instead.


>> 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.


Well ... there is at least one good reason: it evidently conflicts with 
admins who want other kinds of hooks ;-)


>> 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 do not like to see it as at most two hooks, Kallithea's and the 
admins. That will force admins to solve the same problem as we have to: 
Figure out a way to dispatch to multiple hooks. That is an artificial 
and egoistic way to reduce a generic N problem to a "me vs everybody 
else" 2 problem.


> 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


So sad that the Git world seems to rely on hacks instead of solutions :-(

So how about something like 
https://kallithea-scm.org/repos/kallithea-incoming/changeset/027e5f06c7e7 ?

/Mads