Add execution of additional post-receive hooks#78
Add execution of additional post-receive hooks#78tomka wants to merge 2 commits intokubitron:masterfrom
Conversation
|
I'd love to see this feature merged. Current Post-Receive URLs add some complexity to my workflow (a webpage is run as the webserver user, but I'd like to be executed by the gitolite user, so I had to add a workaround...). |
|
Why does the readme explicitly talk about putting hooks into the individual hooks directory of a repository? Wouldn't it make more sense to put them into the top-level .gitolite/hooks/post-receive.d directory? If I understand gitolite, this directory would then be linked into all new repositories...? Alternatively, perhaps it would make sense to support both global and local configuration with two different directory names..? |
|
Supporting both, global and local extra hooks, sounds reasonable. As I only needed local configurations in the first place, I only came up with this addition. So that is why the readme talks only about individual hook directories. Also, I guess per-repo hooks are pretty common. However, I'll add support for global configurations in the next days to this pull request. I propose to have the directory "post-receive.d" for global hooks (linked automatically for new repos) and "post-reseive.local.d" for individual per-repo hooks. |
|
The latest commit adds support for local and global hooks. The commit message states the details. What do you think about it? |
|
Hello. Thank you for your work. Sorry for the delay. I have a couple of folks with hook problems at the moment, so I am going to wait until that is resolved... I may put this into version 0.5.2x. |
|
Hi kubitron, thanks for getting back to this and considering it for a merge. I thought about adding the presentation of all available executable hooks in a projects repository settings (and maybe of the global hooks in the plugin's global settings). What's your opinion on this? |
As this plugin occupies the post-receive hook of a managed repository, no other post-receive hook can be used. To get around this limitation, this commit changes the installed hook in such a way that it looks for additional executable files in a sub-directory of the repository's hook folder. This sub-directory has to be called "post-receive.d". The plugin's hook will execute all the files in there marked as executable and will provide the processes with the same STDIN stream it got when called in the first place.
Up to now the plugin executed additional hooks when they lived in the 'postreceive.d' folder in the hooks folter of a repository. This allwed only for either local or global hooks. To support both use cases at a time, this commit will do two things: 1. The plugin will check whether there is a global hook directory 'post-receive.d' present. If not, the plugin will create it in the common hooks directory of gitolite. Gitolite will link it from every repository automatically. 2. It will execute executables in the folders 'post-receive.d' and 'post-receive.local.d', if present. The first one is meant to be linked to a common folder (see 1.) in gitolite's common hooks folder. The second folder can be used to have additional local per-repository hooks.
|
I just rebased this code to the most recent master branch (fba1f7e). |
3 participants
As this plugin occupies the post-receive hook of a managed repository,
no other post-receive hook can be used. To get around this limitation,
this commit changes the installed hook in such a way that it looks for
additional executable files in a sub-directory of the repository's hook
folder. This sub-directory has to be called "post-receive.d". The
plugin's hook will execute all the files in there marked as executable
and will provide the processes with the same STDIN stream it got when
called in the first place.