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
_______________________________________________
kallithea-general mailing list
[email protected]
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
