gitLab 全局hooks和custom_hooks,以及服务器端自动更新和备份(一)

 写代码的时候,git push到远程代码库后,往往还要连到服务器上pull代码才能进行测试。代码push后自动更新测试服务器的代码也算是一种刚需了。

gitLab的钩子分为两大类:1.web hooks

            2.custom hooks,这是调用git原生钩子,这里的钩子也有两种类型:(1)全局钩子 (2)每个项目对应的钩子。

这几天踩了很多坑,才用一种迂回的方法解决了问题。介绍一下GitLab和ubuntu的版本:Ubuntu 16.04.1 LTS + GitLab Community Edition 9.4.4 和 GitLab Community Edition 8.15.4,两个版本的gitlab配置起来是几乎是一样的。

1.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/A,在dir2/hooks/A,这里两个hooks是软链接的关系,其实是同一个。路径dir1和dir2不同,但是对这两个目录下的hooks目录的文件修改,添加,删除,都同时起作用,因为这个目录本来就是一个。好了,我们看gitlab中是怎样做的:

(1)/opt/gitlab/embedded/service/gitlab-shell/hooks

(2)/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文件夹,这个文件夹和(1)中的是同一个文件夹,这里采用的是软链接方式,虽然路径不同,其实他们指向的是同一个文件夹。

   这个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是否可执行。

 

3.测试钩子是否被执行

(1)在ubuntu上的测试方法:直接在终端上用命令行来测试:

   在客户端建立一个空目录,git init,然后git clone 地址,这样就可以clone一个分支了,然后修改这个里面的文件,比如README文件,git commit -a,添加注释等,最后是git push

  注意,这时在服务器端全局钩子hooks目录下的post-receive就会被调用(这个文件可以是shell脚本,在里面echo "global post-receive ------------------>"),这样的话,如果正常,在客户端的git bash或者客户端的终端中,就会看到这句提示了。这种方法就可以验证服务器端钩子有没有执行。

(2)在windows上的测试方法:建议不要用图像话的工具,比如SmartGit,直接用git bash命令行,好处是服务器端的钩子执行了,如果有提示输出,会直接在命令行中显示remote:******** 如果采用SmartGit这样的图形化节目,可能就看不到这样的输出了。

posted @ 2017-08-17 12:23  懒猫的新窝  阅读(2627)  评论(3编辑  收藏