须知

默认我们利用Gitlab的webhook做CI的时候,会和Jenkins做一个token的认证,来实现CI的集成。
而下面我们采取Jenkins另外一个插件Generic Webhook Trigger,来免去token的认证,可以直接进行CI的集成
(这里可以学会如何在gitlab执行一个push或者merge的时候自动构建,以此我这里还延伸做了代码的自动扫描的操作)

如下是需要token进行集成的,而我们这次是不需要这种密文token来进行集成的

1.png

1、安装Jenkins插件-Generic Webhook Trigger插件

2.png

安装效果如下所示

3.png

2、理解Generic Webhook Trigger插件

$.ref:获取json数据中ref的值,并把值传递给ref变量

(ref变量可以自己取名称,然后在Jenkins上运用,但是$.ref中的ref是根据实际传递过来的json参数获取的key名称)

$.user_name获取json数据中user_name的值,并把值传递给user_name变量

(同理$.user_name和user_name也是和上面ref一样的道理)

4.png

这类变量从 POST 的具体内容中获取,格式支持JSON/XPATH,具体为:
Variable:是变量名
Expression:是变量的获取方式
Value filter:需要过滤的变量内容,一般不填
Default value:变量默认值,一般不填
    其中,如果将 Expression 中设置为 $.a.b.c,即可获取到出下面 JSON 中的“value”。

6.png

3、获取gitlab传递的参数

当操作为push的时候,json数据就有上面引用的两个key

333.png

其他你想要获取的重要的参数,也可以自己去在插件中获取去利用起来

当操作为merge的时候,发送的参数又会不一样,如下所示

7.png

4、如何获取gitlab传递过来的参数呢

从运维的角度来看,可以通过配置nginx,配置$request_body的一个日志输出,然后再进行json的格式转换,就可以转成具体的json格式的请求参数了

5、简单实现当gitlab有人提交合并merge操作的时候,自动触发构建他的工程

这里做一个自动构建,并进行代码扫描的过程

1、Generic Webhook Trigger插件配置和说明

获取json参数

10.png

11.png

配置触发构建工程的token

这个是需要配置到gitlab去的

12.png

格式如下所示:
其中
https://yoursite.com/generic-webhook-trigger/invoke?token=
是固定格式
token,就是jenkins配置的token,一一对应即可

匹配参数才进行构建

13.png

2、代码编译

根据自己企业的项目的代码是如何编译的,进行配置即可

注意:默认Jenkins会构建你设置默认的分支,所以你这里要自己写git相关命令,来构建实际post提交的git分支
可以百度参考其他文档(或者避免麻烦,直接设置成提交origin/dev分支自动构建也是可以的)

3、Sonarqube配置

可以参考其他Sonarqube文档,这里不是重点

注意:这里还涉及到Sonarqube的安装和Jenkins的集成知识,这里不再演示,可以参考百度进行集成操作

4、告警通知

111.png

5、Sonarqube扫描结果

222.png