FWIW this is now enough to satisfy my own use case.
On 1/11/21 5:10 PM, Mads Kiilerich wrote:
On 1/11/21 10:16 PM, Lance Edgar wrote:
On 1/11/21 7:53 AM, Mads Kiilerich wrote:
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.
Thanks, that looks safer.
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 ;-)
Ha, touché. I just have no idea how Kallithea could do what it needed,
without hooks. Maybe I lack imagination but it seems like hooks are
ideal for it.
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.
Understandable. I don't personally have an issue with "at most two
hooks" simply because that is no worse than "at most one hook" which is
default Git behavior. If Kallithea did not need to install a hook at
all, then it would effectively "stay out of the way" and admin would
manage the hooks using their "normal" approach. Since it does need a
post-receive hook, it has the added burden of defining where/how admin
can still configure their own "custom" post-receive hook.
That's just me repeating the obvious maybe.
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
?
That seems to do what I want, so thanks again. I look forward to next
release!
I could imagine a world where Kallithea exposed all available git hooks
for maintenance within the UI, and perhaps had a smart dispatcher(s) to
allow multiple hooks of each type. Who knows maybe that even would add
to the attraction of Kallithea over other options, e.g. GitLab. I don't
think it would have swayed my own decision, which had more to do with
true software freedom. And if the dispatcher needed to be a 3rd party
project then that may just complicate things? Anyway just some more of
my 2c.
Lance
_______________________________________________
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
