Re: [PATCH] git: move non-kallithea hooks and execute other hooks
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
Re: [PATCH] git: move non-kallithea hooks and execute other hooks
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 de
Re: [PATCH] git: move non-kallithea hooks and execute other hooks
https://kallithea-scm.org/repos/kallithea/changeset/Thanks for the reminder of this discussion. Sorry for dropping it. As spin-off from this discussion and Tim Ooms' patch proposal, we landed some changes in the default branch, heading for 0.7 : https://kallithea-scm.org/repos/kallithea/changeset/6a90b1ebea2c hooks will now always be written atomically and will never follow symlinks https://kallithea-scm.org/repos/kallithea/changeset/1089fac66e81 detect hooks that are symlinks as having been changed by the sysadmin, and they will thus (by default) not be overwritten https://kallithea-scm.org/repos/kallithea/changeset/7b809e4a1ea5 use current umask when writing hooks file https://kallithea-scm.org/repos/kallithea/changeset/5de682ee0b06 introduce cli repo-scan options --install-git-hooks and --overwrite-git-hooks https://kallithea-scm.org/repos/kallithea/changeset/92894fccc615 recommend always running repo-scan to reinstall Git hooks after upgrading That's a start. 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. 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?) 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? /Mads On 1/8/21 11:50 PM, Lance Edgar wrote: I'm fairly new to Kallithea but also encountered this problem with my setup. I'm not clear where things are at with this discussion now, but it seems unresolved so wanted to share my perspective. I need the same thing others have mentioned: to effectively have multiple post-receive hooks for certain git repos. Possible solutions appear to be: A) Kallithea hook gets built-in support for running additional hooks, discovered by globbing B) admin must create a Kallithea extension which somehow does that same thing C) admin installs custom hook script which can run the Kallithea hook, plus additional (per glob) Thus far I've gone with option C, because option A doesn't exist and option B seems wrong to me. The only thing I don't really like about C is that Kallithea will no longer update its own hook script. If I'm being honest I think option A should exist and if so I'd use it. On 11/4/20 3:14 AM, Tim Ooms wrote: On 24/10/2020 13:05, Mads Kiilerich wrote: On 10/23/20 9:30 AM, Tim Ooms wrote: It might have rough edges to bypass Kallithea when accessing Kallithea-managed repos. It is perhaps better to go with the assumption that Kallithea fully owns the repositories it manage. I tried to not bypass Kallithea by letting it execute the other hooks. I know the mercurial hooks are more integrated, but as the git hooks don't work the same way I think this is the next best thing. Although there may be better ways, I'm not sure. If you only access the repos through Kallithea, I think it would be better to run your hooks as Kallithea extensions. I'm not sure that's possible right now, but we can perhaps fix that. It seems t
