使用 GitLab 自定义接收后文件 [英] Custom post-receive file using GitLab

问题描述

我正在尝试将 GitLab 自动生成的 post-receive 钩子替换为启用邮件支持的新文件，因此必须触发post-receive".

这是我的文件的以前版本:

#!/usr/bin/env bash# 这个文件是由 GitLab 放在这里的.它确保您推送的提交# 将被正确处理.在阅读 oldrev newrev ref 时做# 对于推送的每个分支或标签，在 redis 中创建一个 Resque 作业.repo_path=`密码`env -i redis-cli rpush resque:gitlab:queue:post_receive""{"class":"PostReceive","args":["$repo_path","$oldrev","$newrev","$ref","$GL_USER"]}">/dev/null 2>&1完毕

当我用一个在文件末尾包含上述行的新文件替换该文件时，GitLab 说:项目的接收后文件无效"在管理区域，但电子邮件已正确发送.

您知道如何处理多个接收后支持的问题吗?目前我不知道文件的gitlab特定部分是否正确执行.

感谢您的帮助！

更新:

现在使用下面提到的解决方案(拉取请求)调用文件夹中的脚本.但是我不明白为什么标准的post-receive-email"脚本如果包含在目录中就不会发送任何邮件.如果直接作为 post-receive 调用就可以了.

不知道为什么我必须更改订单，但以下内容对我有用(即使我不知道现在是否正确创建了 resque 作业:

#!/usr/bin/env bashrepo_path=`密码`if [ -d hooks/post-receive.secondary.d ];然后对于我在 hooks/post-receive.secondary.d/*做[ -x $i"] ||继续# 使用我们得到的相同参数调用 hooklet路径=$repo_path"/"$i$路径"$@"||{# hooklet 失败；我们需要记录它...echo hooklet $i 失败perl -I$GL_BINDIR -Mgitolite -e log_it('hooklet $i failed')"# ...并返回一些非零退出代码;-)1号出口}完毕菲在阅读 oldrev newrev ref 时做# 对于推送的每个分支或标签，在 redis 中创建一个 Resque 作业.env -i redis-cli rpush resque:gitlab:queue:post_receive""{"class":"PostReceive","args":["$repo_path","$oldrev","$newrev","$ref","$GL_USER"]}">/dev/null 2>&1完毕出口 0

解决方案

2014 年更新，GitLab 不再使用 gitolite:

正如 下面提到的 Ciro Santilli，现在有一种官方方式 设置自定义挂钩(GitLab 7.5.0+，2014 年 11 月).

<块引用>

1. 选择一个需要自定义 git 挂钩的项目.
2. 在 GitLab 服务器上，导航到项目的存储库目录.
   对于手动安装，路径通常是 /home/git/repositories/<group>/<project>.git.
   对于 Omnibus 安装，路径通常是 /var/opt/gitlab/git-data/repositories/<group>/<project>.git.
3. 在此位置创建一个名为 custom_hooks 的新目录.
4. 在新的 custom_hooks 目录中，创建一个名称与挂钩类型匹配的文件.
   对于 pre-receive 挂钩，文件名应为 pre-receive 且不带扩展名.
5. 使钩子文件可执行并确保它归 git 所有.
6. 编写代码，使 git 钩子按预期运行.Hooks 可以是任何语言.确保顶部的shebang"正确反映语言类型.
   例如，如果脚本在 Ruby 中，则 shebang 可能是 #!/usr/bin/env ruby​​.

<小时>

原始答案(2013 年 1 月)

这个(允许自定义挂钩)已通过 拉取请求 555 和 commit 2245a6bbe，当时 GitLab 正在使用更新后挂钩.

您需要在由 gitolite 和 GitLab 管理的 git 裸仓库中声明一个 hooks/post-receive.secondary.d.
把你所有的更新后挂钩放在那里.

您可以修改 gitolite 发布的更新后挂钩 遵循该模型:如果检测到，它将调用您所有的更新后挂钩.

<小时>

问题是:

使用 Gitolite V2，GitLab 最终将管理权委托给 Gitolite，因为您可以 declare post-update.secondary 挂钩，Gitolite 本身会调用.

使用 Gitolite V3，不再有任何保留的钩子(除了gitolite-admin repo 中的更新版本)，因此没有 gitolite 辅助"机制.
但是 GitLab(现在使用 post-receive hook)尚未更新其 hook 管理以考虑到新的现实(gitolite 不再允许辅助 hook).

I'm trying to replace my post-receive hook, auto-generated by GitLab by a new file which enables mail-support and thus has to be triggered "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 that file by a new one which includes the above mentioned lines at the end of the file, GitLab says: "Project has invalid post-receive file" in the admin area but emails are correctly sent.

Do you know how to handle that problem of multiple post-receive support. At the moment I don't know if the gitlab specific part of the file is correctly executed at all.

Thanks for help!

Update:

The scripts within the folders are invoked now by using the below mentioned solution (pull request). But I don't understand why the standard "post-receive-email"-script doesn't send any mails if it is included in the directory. It works fine if it is invoked directly as post-receive.

Don't know why I have to change the order, but the following works for me (even I don't know if resque jobs are now created properly:

#!/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

解决方案

Update 2014, with GitLab not using gitolite anymore:

As mentioned below by Ciro Santilli, there is now an official way to setup custom hooks (GitLab 7.5.0+, Nov. 2014).

1. Pick a project that needs a custom git hook.
2. On the GitLab server, navigate to the project's repository directory.
   For a manual install the path is usually /home/git/repositories/<group>/<project>.git.
   For Omnibus installs the path is usually /var/opt/gitlab/git-data/repositories/<group>/<project>.git.
3. Create a new directory in this location called custom_hooks.
4. Inside the new custom_hooks directory, create a file with a name matching the hook type.
   For a pre-receive hook the file name should be pre-receive with no extension.
5. Make the hook file executable and make sure it's owned by git.
6. Write the code to make the git hook function as expected. Hooks can be in any language. Ensure the 'shebang' at the top properly reflects the language type.
   For example, if the script is in Ruby the shebang will probably be #!/usr/bin/env ruby.

---

Original answer (January 2013)

This (allowing custom hooks) has been resolved with pull request 555 and commit 2245a6bbe, at the time where GitLab was using post-update hooks.

You need to declare a hooks/post-receive.secondary.d in your git bare repo managed by gitolite and GitLab.
Put all your post-update hooks in there.

You could modify the post-update hook posted by gitolite following that model: it will call all your post-update hooks if detected.

---

The issue is:

With Gitolite V2, GitLab finally delegated that management to Gitolite, because you could declare post-update.secondary hooks, that Gitolite itself would call.

With Gitolite V3, there is no longer any reserved hook (beside the update one in the gitolite-admin repo), so there is no gitolite "secondary" mechanism.
But GitLab (which now uses post-receive hook), hasn't yet updated its hook management to take into account that new reality (of gitolite not allowing anymore secondary hooks).

这篇关于使用 GitLab 自定义接收后文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！