gitLab 全局hooks和custom

鄂破机看

　　写代码的时候，git push到远程代码库后，往往还要连到服务器上pull代码才能进行测试。代码push后自动更新测试服务器的代码也算是一种刚需了。
　　gitLab的钩子分为两大类：１．web hooks
　　２．custom hooks，这是调用git原生钩子，这里的钩子也有两种类型：（１）全局钩子　（２）每个项目对应的钩子。
　　这几天踩了很多坑，才用一种迂回的方法解决了问题。介绍一下GitLab和ubuntu的版本：Ubuntu 16.04.1 LTS + GitLab Community Edition 9.4.4　和　GitLab Community Edition ８.15.4，两个版本的gitlab配置起来是几乎是一样的。
　　１．web hooks
　　官方文档：https://docs.gitlab.com/ee/user/project/integrations/webhooks.html
　　这里就不重点介绍了，主要介绍让我踩了很多坑的custom hooks
　　2.　custom hooks
　　官方文档：https://docs.gitlab.com/ee/administration/custom_hooks.html#custom-git-hooks
　　这里的官网文档有句：Normally, Git hooks are placed in the repository or project's hooks directory. GitLab creates a symlink from each project's hooks directory to the gitlab-shell hooks directory for ease of maintenance between gitlab-shell upgrades.
　　这里的symlink是软链接，类似windows的快捷方式，但是还是有区别：以gitlab中的hooks目录为例：
　　在dir1/hooks/Ａ，在dir2/hooks/A，这里两个hooks是软链接的关系，其实是同一个。路径dir1和dir2不同，但是对这两个目录下的hooks目录的文件修改，添加，删除，都同时起作用，因为这个目录本来就是一个。好了，我们看gitlab中是怎样做的：
　　（１）/opt/gitlab/embedded/service/gitlab-shell/hooks
　　（２）/var/opt/gitlab/git-data/repositories/root/Test.git/
　　官方文档指出：For Omnibus installs the path is usually /var/opt/gitlab/git-data/repositories/<group>/<project>.git
　　每个组用户，对应项目下有个hooks文件夹，这个文件夹和（１）中的是同一个文件夹，这里采用的是软链接方式，虽然路径不同，其实他们指向的是同一个文件夹。
　　这个hooks文件（以下说的hooks目录都是指上面2个路径的目录，他们是软链接关系，其实只有一个实体），有三个文件post-receive，update和pre-receive钩子，这是服务器钩子（git也有服务器钩子和客户端钩子，gitLab类似）。
　　当客户端push之后，服务器会钩子会触发，其中就有这个post-receive，实现自动更新，就需要在这个post-receive钩子的时候，执行一些脚本操作。这个hooks文件夹里的钩子是全局钩子，我们需要的是每个项目自定义的钩子。
　　按照官方的文档说明的步骤　https://docs.gitlab.com/ee/administration/custom_hooks.html#custom-git-hooks
　　简而言之，就是在/var/opt/gitlab/git-data/repositories/<group>/<project>.git目录下建立一个custom_hooks的目录，这个目录下放文件名符合钩子规范的钩子，比如post-receive,update, pre-receive等，注意没有后缀名。还有就是需要修改权限，让他们可以执行，并且保证这个目录和目录下的文件的所有权属于git用户。可以参考：http://blog.hgomez.net/2015/03/02/Gitlab-custom-hooks-Bash-Way.html
　　但是奇怪的是，我安装这个步骤仔细检查和修改了几遍，就是没有生效，感觉是哪里出了问题，这个每个工程自定义的钩子好像不能被gitLab调用一样。看了hooks文件夹下的post-receive才有了思路，虽然这个是ruby语言编写的，看这行：

　　感觉是先new一个全局钩子，进行调用，然后再new一个custom_hooks进行调用，原来是我之前把原版的ruby版的post-receive钩子屏蔽了，直接用shell写了个post-receive钩子，放在hooks目录下了，当然就不去调用custom_hooks目录下的钩子了，官方文档貌似没对这说明。
　　不同版本的gitLab，if后面的函数参数可能不同，这里有GitlabCustomHook，还有那个头文件gitlab_custom_hook，去看看这个头文件里面有什么。

　　61-65的注释已经显示了查找钩子的目录，第71行和第75行，可以看出custom_hooks这个文件夹的的名称已经是写死的，第78行的注释可以看出，gitlab的配置文件中，custom_hook_dir项不设置的话，就会直接在hooks目录下查找全局钩子。gitlab的配置文件目录/etc/gitlab/gitlab.rb

　　这里就没必要设置这个，顺便说一句，改了这个配置文件后，需要gitlab-ctl reconfigure之后才能生效（会重新编译，重起服务，还有会覆盖每个工程下面的自动配置文件）。
　　弄清楚了这些，就可以在需要自定义钩子的目录下自己建立一个custom_hooks钩子

　　查看文件夹的拥有者是谁，查看文件夹的命令是：ls -ld custom_hooks/
　　会看到拥有者是当前终端登陆的用户，修改为git拥有者的命令是: chown -R git:git custom_hooks/
　　进入custom_hooks文件夹，建立我们需要的钩子post-receive，没有后缀名，修改拥有者为git:chown -R git:git post-receive, 修改权限：chmod 755 post-receive
　　测试./post-receive是否可执行。
　　３．测试钩子是否被执行
　　（１）在ubuntu上的测试方法：直接在终端上用命令行来测试：
　　在客户端建立一个空目录，git init，然后git clone 地址，这样就可以clone一个分支了，然后修改这个里面的文件，比如README文件，git commit -a，添加注释等，最后是git push
　　注意，这时在服务器端全局钩子hooks目录下的post-receive就会被调用（这个文件可以是shell脚本，在里面echo "global post-receive ------------------>"），这样的话，如果正常，在客户端的git bash或者客户端的终端中，就会看到这句提示了。这种方法就可以验证服务器端钩子有没有执行。
　　（２）在windows上的测试方法：建议不要用图像话的工具，比如SmartGit，直接用git bash命令行，好处是服务器端的钩子执行了，如果有提示输出，会直接在命令行中显示remote:********　如果采用SmartGit这样的图形化节目，可能就看不到这样的输出了。