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