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

问题描述

我试图用一个支持邮件支持的新文件来替换我的post-receive hook，它由GitLab自动生成，因此必须触发post receive。

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

 ＃！/ usr / bin / env bash 
 
＃这个文件被GitLab放在这里。它确保您的推送提交
＃将被正确处理。 
 
 while read oldrev newrev ref 
 do 
＃对于每个被推送的分支或标签，在redis中创建一个Resque作业。 
 repo_path =`pwd` 
 env -i redis-cli rpushresque：gitlab：queue：post_receive{\class \：\PostRe 
 ceive \ \ args\：\ $ repo_path\，\ $ oldrev\，\ $ newrev\，\ $ ref\，\ $ GL_USER\]} 
> / dev / null 2>& 1 
 done 
  

GitLab在管理区域中说：项目有无效的post-receive文件，但邮件正确发送。

<你知道如何处理多个收到后支持的问题。目前我不知道该文件的gitlab特定部分是否正确执行。

感谢您的帮助！

更新：

现在使用下面提到的解决方案（拉取请求）调用文件夹中的脚本。但我不明白为什么标准的post-receive-email-script如果包含在目录中不会发送任何邮件。它可以正常工作，如果它直接作为post-receive被调用。

不知道为什么我必须改变顺序，但以下工作适用于我（即使我不't知道resque作业现在是否已正确创建：

 ＃！/ usr / bin / env bash 
 
 repo_path =`pwd` 
 
 if [-d hooks / post-receive.secondary.d];然后
 
用于hook in / post-receive.secondary。 d / * 
 do 
 [-x$ i] || continue 
＃使用与我们获得的相同参数调用小钩子
 path = $ repo_path/$ i 
$ path$ @|| {
＃hooklet失败;我们需要记录它... 
 echo hooklet $我失败
 perl -I $ GL_BINDIR  - Mgitolite -elog_it（'hooklet $ i failed'）
＃...并返回一些非零退出码;-) 
 exit 1 
} 
完成
 
 fi 
 
 while read oldrev newrev ref 
 do 
＃对于每个被推送的分支或标签，在redis中创建一个Resque作业。 
 env -i redis-cli rpushresque：gitlab：queue：post_receive{\class \：\PostReceive \，\args \：[\ $ repo_path\，\$ oldrev\，\$ newrev\，\$ ref \，\$ GL_USER\]}> / dev / null 2>& 1 
 done 
 
 exit 0 
  

解决方案

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

As Ciro Santilli https://stackoverflow.com/a/27520784/6309\">下面提到 >，现在有官方的方式 设置自定义钩子 （GitLab 7.5.0+，2014年11月）。

1. 选择一个需要定制git钩子的项目。


2. 在GitLab服务器上，导航到项目的存储库目录。
   
   对于手动安装，路径通常是 / home / git / repositories /< group> /< project> .git 。
   
   对于Omnibus安装，路径通常是在/ var /选择/ gitlab / git的数据/ reposit ories /< group> /< project> .git 。


3. 在这个位置创建一个名为 custom_hook
   
4. 在新的 custom_hooks 目录中，创建一个名称与钩子类型匹配的文件。
   
   对于 pre-receive 钩子，文件名应该是 pre-receive ，不能包含扩展名。


5. 使钩子文件成为可执行文件，并确保它是git拥有的。


6. 编写代码以使git钩子函数符合预期。挂钩可以是任何语言。确保顶部的'shebang'正确地反映语言类型。
   
   例如，如果脚本在Ruby中，shebang可能会是＃！/ usr / bin / env ruby










---

原始答案（2013年1月）

这个（允许自定义挂钩）已经通过 pull request 555 and commit 2245a6bbe ，当时GitLab使用post-update钩子。

你需要声明一个 hooks / post-receive.secondary.d 在gitolite和GitLab管理的git bare repo中。

将所有更新后的钩子放在那里。

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

< hr>

问题是：

使用Gitolite V2，GitLab最终将该管理委托给Gitolite，因为您可以声明post-update.secondary钩子，即Gitolite本身会调用的。

对于Gitolite V3，不再有任何保留（在gitolite-admin回购中的更新旁边），所以没有gitolitesecondary机制。

但是GitLab（它现在使用Post-receive钩子），还没有但更新了其钩子管理，以考虑到新的现实（gitolite不允许再有二级钩子）。

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屋！