webhook是gitlab或者github的重要功能。这篇文章将会通过一个实例来演示一下如何使用webhook。
使用场景
为什么要使用WebHook，自动化或者是持续集成或者持续部署的是其重要原因，结合TDD的框架，能够做到很多事情。比如修改某个bug，我们只修改了一行，修改之后，使用git 进行commit提交然后push，
然后通过jenkins来取得代码进行自动构建等CI操作。但是这个中间有一个衔接问题，Jenkins如何知道Gitlab有人往上push呢，这个有很多种对应方法，比较自然的一种则可以使用webhook的方式。
Webhook跟很久远之前我们写钩子一样，c里面就是一个callback，而面向对象的c++/或者java则可能是模板模式的应用，push这个动作的发生是一种事件，监控这类事件并提供Hook就是Webhook所作的事情。
gitlab的webhook
gitlab的webhook可以通过选中某个project的repository的页面的设置按钮菜单进行选择，如下图 
也可以通过 group名称/project名称/hooks的URL方式反问 
webhook支持的事件
目前所使用的gitlab的版本所支持的webhook，有如下9种。
| 项番 | 事件 | 说明 |
|---|---|---|
| No.1 | Push 事件 | URL 被触发的原因： 向当前仓库的push动作 |
| No.2 | Tag push 事件 | URL 被触发的原因： tag被push到当前仓库 |
| No.3 | Comments | URL 被触发的原因： 某人添加了一条comment |
| No.4 | Issues 事件 | URL 被触发的原因： 当一个issue被创建/更新/合并时 |
| No.5 | Confidential Issues 事件 | URL 被触发的原因： 当一个confidential issue被创建/更新/合并时 |
| No.6 | Merge Request 事件 | URL 被触发的原因： 当一个merge request被创建/更新/合并时 |
| No.7 | Build 事件 | URL 被触发的原因： 当构建状态变化时 |
| No.8 | Pipeline 事件 | URL 被触发的原因： 当pipeline状态变化时 |
| No.9 | Wiki Page 事件 | URL 被触发的原因： 当wiki页面被创建或者更新时 |
创建
简单来说，webhook的功能大体就是指定某种事件发生时候，被设定的URL会被执行。接下来我们来创建一个webhook。
准备
在那之前，我们需要做一个服务并运行起来，也就是那条URL执行的时候确实保证能是OK的。为了简单起见，使用https://requestb.in/所提供的功能来做这个事情
使用https://requestb.in/创建一个服务
Click 按钮Create a RequestBin按钮创建一个可以进行验证的webhook URL
直接在URL里面输入https://requestb.in/12gwt3h1确认返回的OK，或者如下方式通过curl都能得到确认的结果(ok)
[root@ku8-1 gitlab]# curl -X POST -d "fizz=buzz" https://requestb.in/12gwt3h1
ok[root@ku8-1 gitlab]# 创建webhook
输入刚才生成的URL，创建一个webhook，此webhook受push事件触发 
结果确认
生成的webhook所在行有个test按钮，执行可在头部确认状态，返回200，说明webhook已通。 
System hooks
除了对仓库的操作之外，对用户或者project的操作也能进行hook，此种hook在gitlab中被称为system hooks，不再一一赘述。 
总结
通过这篇文章，我们了解到了webhook的机制，以及gitlab的9种触发事件，通过一个简单的例子进行设定，使得我们意识到合理利用这项功能确实能切实的促进持续集成的粒度。
参考
https://lostechies.com/derickbailey/2014/03/11/testing-stripe-com-webhooks-with-requestb-in/
https://docs.gitlab.com/ee/user/project/integrations/webhooks.html