本文已参与「新人创造礼」活动,一起开启创造之路

前语

在之前的CI/CD流程中,我在装备Jenkins Job的“构建触发器”时,选用的都是Gitlab的轮询战略,每10分钟轮询一次Gitlab代码库房,若有新代码提交,则触发构建、履行代码扫描、运转主动化测验等一系列动作。此种方式的优点是能够灵敏定义轮询的时刻距离,比如每10分钟、每1小时、每天8点、每周五轮训一次等,不足之处便是不行及时,而webhook钩子刚好能够弥补这种不足:即在Gitlab库房装备完webhook,Gitlab库房检测到如代码提交或其他自定义事件时,即可当即触发Jenkins构建。本篇为webhook的装备进程记录、趟坑大全、处理方案、常见报错问题的通用排查思路,以及一些个人考虑总结。

一、装备步骤

1.在Jenkins端装置Gitlab触发器插件

装置如图所示插件,装置完成后重启Jenkins收效

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

2.在Jenkins job中装备触发器

构建触发器中选择“Build when a change is pushed to Gitlab……”,并记住webhook URL。

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

3.Gitlab中装备webhook

Gitlab指定代码库房-设置-Webhooks,将构建触发器中的webhook url复制到Webhooks地址栏中

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

4.测验webhook

新建完成后,Project Hooks中会显示新创立的webhook,能够点击右侧下拉框中的“测验”,发送恳求测验与Jenkins之间的连通性。若回来200,则阐明连通性正常,若回来400、401、500等则阐明装备有问题。当然如果装备进程这么顺畅的话,也就不会有这篇文章的存在。既然是趟坑大全,必然会有一个又一个坑在等着我。

二、趟坑大全

坑一:“ Urlis blocked: Requests to the local network are not allowed”

将Jenkins构建触发器中提示的URL,装备到gitlab待测验项目的库房下的webhooks中,保存时提示 “ Urlis blocked: Requests to the local network are not allowed”

【原因】

官方解说:docs.gitlab.com/ee/security… 10.6 版别今后为了安全,默许不允许向本地网络发送webhook恳求,能够修改默许值

【处理办法】

以管理员身份在设置-网络-外发恳求中勾选“允许Webhook和服务对本地网络的恳求”

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

坑二:忘掉Gitlab管理员暗码

第一次建立完Gitlab时,管理员暗码是保存在Gitlab装备目录的一个文件下,暗码是一堆字符串,底子记不住,并且第一次登录后,该文件会主动删除。好在Gitlab服务是我建立的,能够经过一些途径重置管理员暗码:

gitlab-rails console   # 进入gitlab-rails控制台
user = User.where(id:1).first  # 查询第一个用户的信息,看是不是root用户
user.password='root123456'  # 将暗码设为123456
user.save  # 保存设置

如下图所示:

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

坑三:gitlab管理员勾选“允许Webhook和服务对本地网络的恳求”保存时报错500

也便是按照坑一的处理方法操作时,Gitlab会报错500

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

这个问题排查了很久,在一些软件测验群里或是查找引擎上也没找到类似问题的处理方案,毕竟Gitlab 500是一种很常见的报错,或许由许多种原因导致。但此刻Gitlab是正常工作的,因而能够排除网络上常见的一些原因。后来经过gitlab-ctl tail检查日志发现了报错的详细信息:

【原因】

经过在网上查找报错信息得知,报错是由于gitlab更新到高版别(13.8.8后),”管理员设置不可注册的操作报错“,本来是我的Gitlab版别太高了…

【处理办法】

gitlab-rails c  # 进入gitlab指令行
# 依次履行如下指令:
settings = ApplicationSetting.last
settings.update_column(:runners_registration_token_encrypted, nil)
settings.update_column(:encrypted_ci_jwt_signing_key, nil)
settings.save!

如下图所示:

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

此刻,再用管理员保存Gitlab网络装备时,即可保存成功:

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

坑四:gitlab添加Webhook后,测验发送恳求,提示401

我认为Gitlab管理员暗码也找回了,网络装备也设置完了,应该能够正常发送恳求到Jenkins了,没想到刚测验发送恳求,就提示“Hook executed successfully but returned HTTP 401”

【原因】

Jenkins拜访安全问题,Jenkins和Gitlab之间没有建立信任关系。

【处理办法】

需要在Jenkins用户-设置-API TOKEN中添加一个token,并在gitlab的webhook中装备时,如“http://admin:11f3dd13297766a1546d455e73933eb4cc@192.168.1.122:8088/jenkins/project/TEST-RS-OTMS”

坑五:gitlab添加Webhook后,测验发送恳求,提示403

处理坑四、在Jenkins添加完token、重新装备webhook URL后,再次发送恳求,提示“Hook executed successfully but returned HTTP 403…..“,我便是不气馁,再次查找处理方案。

【原因】

Jenkins拜访权限问题

【处理办法】

需要在Jenkins体系设置中撤销勾选“Enable authentication for ‘/project’ end-point”

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

坑六:gitlab添加Webhook后,测验发送恳求,提示500

搞完坑五的装备,测验发送恳求,提示“Hook executed successfully but returned HTTP 500”。NND,我仍是不气馁,再次查找处理方案,还真被我找到了一个遇到和我一模一样问题的人。

【处理办法】

本来URL中的project要改为job(猜测或许是高版别Jenkins才有的问题,毕竟许多教程上,人家都是用的project)

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

坑七:gitlab测验发送恳求,回来200,但是提交代码未触发Jenkins构建

认为回来200就功德圆满了,没想到仅仅是回来了200,Jenkins Job那边没有丝毫动态,也便是webhook没有触发Jenkins的履行,肯定哪里还有躲藏的坑,再次查找处理方案……

【处理办法】

URL最后要加个build,完整的形式:http://用户名:API token @IP+端口/jenkins/job/项目名称/build

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

坑八:Jenkins被webhook屡次无规则触发构建

在处理完坑七后,再次测验发送恳求,这次总算能够成功触发Jenkins构建了。但随之而来又遇到了匪夷所思的问题,Jenkins无端端地被屡次触发构建(企业微信收到了多封邮件)。

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

【问题排查】:

① 开始分析:起初我认为是不是团队中有其他人提交代码所造成的,但看了Gitlab代码提交记录,只有我一个人提交代码。

② 再次分析:或许是我同时装备了Gitlab轮询战略导致,但重新检查了一遍Jenkins Job的装备,只有Webhook一种构建触发器,且根据邮件上的构建时刻来看,几回的构建时刻距离没有任何规则,此原因也能够排除。

③ 持续分析:没过多会,”作用域“一词在我脑海中不断闪现:会不会是我创立的webhook位置创立错了,由于第一次在项目下创立时,遇到了坑一、二、三的各种报错,没有创立成功,后来在Gitlab的大局设置-Webhooks下创立成功了。此次或许和创立位置有关,也便是Gitlab的任意代码库房有代码提交,都会触发Jenkins进行构建。为了验证这种猜测,我特意问了前端的开发搭档,由于只有他们的代码是提交到Gitlab,后端是提交到SVN。果然当天下午有多位前端搭档提交代码,且提交时刻根本与我收到邮件告诉的时刻相吻合。

④ 终极验证:为了完全验证猜测,我请某位搭档再次提交了代码,果然随后Jenkins立马就被触发构建,我也收到了邮件告诉。问题总算找到了!

【处理办法】

将webhook装备在gitlab的待测验项目的代码库房下。

三、测验Webhook

提交代码,验证webhook:

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

Jenkins已经成功触发了构建:

Gitlab配置webhook趟坑全纪录&由此引发的常见环境问题排查思路与思考总结

四、总结与考虑

以上便是案例”运用Gitlab的webhook钩子触发Jenkins主动履行构建“的装备全进程、各种常见不常见的问题报错、处理方案,以及遇到疑难问题的排查思路,也相同适用于其他环境建立/软件工具运用/代码运转进程中的疑难问题,那便是:

  • 遇到问题,先不要着急,能够先看报错信息,根据经验去处理;
  • 经验处理不了,能够在网上查找其他人是否遇到过同类问题;
  • 网上搜不到的,能够咨询身边有经验的搭档、朋友或同学,但问题描述需详细、切当,如问题产生的背景、前因后果,报错的信息、截图,已经尝试过的处理方法等;
  • 问也问不到人的,那就只能不断尝试各种猜测,不断置疑,并且根据此种置疑去不断验证,逐个排除;
  • 还有一个极为重要且有用的,便是检查该体系/软件的日志,有报错日志最好,没有报错日志就边操作复现边看日志信息;
  • 不轻言放弃的精力;

我看过网上的许多教程,他们装备进程都很顺畅,三言两语就搞定了。在遇到一些疑难问题后,我也咨询过一些同行,他们都没遇到过我这么多的问题,我甚至开始置疑自己,简直是趟坑达人。不过,这也不完全是坏处,事物总有两面性,以下是一些考虑总结:

  • 遇到困难不可怕,这次遇到的问题多一些,今后遇到的问题就会少一些,毕竟许多坑都已经趟过来了;
  • 趟坑的目的是为了下次不再遇到坑,所谓失败乃成功之母,今后即便遇到了,也能够从容应对;
  • 是问题,总会有处理办法,一时想不到,不必焦躁,不必死磕,晾一晾,转化一下思路,说不定第二天就会”山重水复疑无路,柳暗花明又一村“!