Custom Post Receiving File Using GitLab

Question

I am trying to replace my post-receive hook, automatically generated by GitLab, with a new file that allows mail support and therefore should be called "post receive".

This is the previous version of my file:

#!/usr/bin/env bash # This file was placed here by GitLab. It makes sure that your pushed commits # will be processed properly. while read oldrev newrev ref do # For every branch or tag that was pushed, create a Resque job in redis. repo_path=`pwd` env -i redis-cli rpush "resque:gitlab:queue:post_receive" "{\"class\":\"PostRe ceive\",\"args\":[\"$repo_path\",\"$oldrev\",\"$newrev\",\"$ref\",\"$GL_USER\"]} " > /dev/null 2>&1 done 

When I replace this file with a new one that includes the above lines at the end of the file, GitLab says: “The project has an invalid post-receive file” in the administration area, but the letters are sent correctly.

You know how to deal with this issue of multiple support after receiving. At the moment, I don’t know if the specific part of the gitlab file is executed correctly.

Thanks for the help!

Update:

Scripts in folders are now called using the solution below (pull request). But I don’t understand why the standard "post-receive-email" script does not send any emails if it is included in the directory. It works great if it is called immediately after sending.

I don’t know why I need to change the order, but the following works for me (even I don’t know if the resque jobs are created correctly:

 #!/usr/bin/env bash repo_path=`pwd` if [ -d hooks/post-receive.secondary.d ]; then for i in hooks/post-receive.secondary.d/* do [ -x "$i" ] || continue # call the hooklet with the same arguments we got path=$repo_path"/"$i "$path" " $@ " || { # hooklet failed; we need to log it... echo hooklet $i failed perl -I$GL_BINDIR -Mgitolite -e "log_it('hooklet $i failed')" # ...and send back some non-zero exit code ;-) exit 1 } done fi while read oldrev newrev ref do # For every branch or tag that was pushed, create a Resque job in redis. env -i redis-cli rpush "resque:gitlab:queue:post_receive" "{\"class\":\"PostReceive\",\"args\":[\"$repo_path\",\"$oldrev\",\"$newrev\",\"$ref\",\"$GL_USER\"]}" > /dev/null 2>&1 done exit 0 

Answer 1

2014 update when GitLab no longer uses gitolit:

Like the Ciro Santilli mentioned below , there is now an official way to configure custom interceptors (GitLab 7.5.0+, November 2014).

• Select a project that requires a custom git hook.
• On the GitLab server, navigate to the project repository directory.
  For manual installation, the path is usually /home/git/repositories/<group>/<project>.git .
  To install Omnibus, the path is usually /var/opt/gitlab/git-data/repositories/<group>/<project>.git .
• Create a new directory at this location named custom_hook s.
• Inside the new custom_hooks directory custom_hooks create a file with a name that matches the hook type.
  For pre-receive hook, the file name must be pre-receive without extension.
• Make the hook executable and make sure it belongs to git.
• Write code to make the hook git function as expected. Hooks can be in any language. Make sure the "shebang" above correctly reflects the type of language.
  For example, if the script is in Ruby, shebang will probably be #!/usr/bin/env ruby .

---

Original answer (January 2013)

This (allowing user hooks) was resolved using a 555 delete request and commit 2245a6bbe , while GitLab was using post-update hooks.

You need to declare hooks/post-receive.secondary.d in your git bare repo, managed by gitolite and GitLab.
Put all your hooks after the upgrade.

You can change the post-update hook sent by gitolite after this model : it will call all your hooks after the update if they are detected.

---

Problem:

With Gitolite V2, GitLab finally delegated this control to Gitolite because you could declare post-update.secondary hooks that Gitolite is calling.

There is no longer a reserved hook with Gitolite V3 (next to the update in the gitolite-admin repository), so there is no guitar-like "secondary" mechanism.
But GitLab (which now uses the hook after reception) has not yet updated its hook management to take into account that the new reality (the guitarolt does not allow more secondary hooks).

Answer 2

Custom interceptors

GitLab recently added a custom hooks function as regular hooks are used internally: https://github.com/gitlabhq/gitlabhq/blob/667c0a909bde1cf71f21d8ec9768e98b1c489030/doc/hooks/custom_hooks.md

Basically, you just create the custom_hooks directory in your Git repo declaration and put the hooks in it, and GitLab ensures that they will run.

Answer 3

Another possible solution to this problem might be:

 #!/usr/bin/env bash while read oldrev newrev ref do # For every branch or tag that was pushed, create a Resque job in redis. repo_path=`pwd` env -i redis-cli rpush "resque:gitlab:queue:post_receive" "{\"class\":\"PostReceive\",\"args\":[\"$repo_path\",\"$oldrev\",\"$newrev\",\"$ref\",\"$GL_USER\"]}" > /dev/null 2>&1 /path/to/your/hook $oldrev $newrev $ref done 

Regarding email notifications, I suggest using this email hook. Alternatively, you can use git-notifier and replace /path/to/your/hook $oldrev $newrev $ref with /path/to/git-notifier/