本文已参与「新人创造礼」活动，一起开启创造之路
前语
在之前的CI/CD流程中，我在装备Jenkins Job的“构建触发器”时，选用的都是Gitlab的轮询战略，每10分钟轮询一次Gitlab代码库房，若有新代码提交，则触发构建、履行代码扫描、运转主动化测验等一系列动作。此种方式的优点是能够灵敏定义轮询的时刻距离，比如每10分钟、每1小时、每天8点、每周五轮训一次等，不足之处便是不行及时，而webhook钩子刚好能够弥补这种不足：即在Gitlab库房装备完webhook，Gitlab库房检测到如代码提交或其他自定义事件时，即可当即触发Jenkins构建。本篇为webhook的装备进程记录、趟坑大全、处理方案、常见报错问题的通用排查思路，以及一些个人考虑总结。
一、装备步骤
1.在Jenkins端装置Gitlab触发器插件
装置如图所示插件，装置完成后重启Jenkins收效
2.在Jenkins job中装备触发器
构建触发器中选择“Build when a change is pushed to Gitlab……”，并记住webhook URL。
3.Gitlab中装备webhook
Gitlab指定代码库房-设置-Webhooks，将构建触发器中的webhook url复制到Webhooks地址栏中
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管理员暗码
第一次建立完Gitlab时，管理员暗码是保存在Gitlab装备目录的一个文件下，暗码是一堆字符串，底子记不住，并且第一次登录后，该文件会主动删除。好在Gitlab服务是我建立的，能够经过一些途径重置管理员暗码：
gitlab-rails console # 进入gitlab-rails控制台
user = User.where(id:1).first # 查询第一个用户的信息，看是不是root用户
user.password='root123456' # 将暗码设为123456
user.save # 保存设置
如下图所示：
坑三：gitlab管理员勾选“允许Webhook和服务对本地网络的恳求”保存时报错500
也便是按照坑一的处理方法操作时，Gitlab会报错500
这个问题排查了很久，在一些软件测验群里或是查找引擎上也没找到类似问题的处理方案，毕竟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网络装备时，即可保存成功：
坑四：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后，测验发送恳求，提示500
搞完坑五的装备，测验发送恳求，提示“Hook executed successfully but returned HTTP 500”。NND，我仍是不气馁，再次查找处理方案，还真被我找到了一个遇到和我一模一样问题的人。
【处理办法】
本来URL中的project要改为job（猜测或许是高版别Jenkins才有的问题，毕竟许多教程上，人家都是用的project）
坑七：gitlab测验发送恳求，回来200，但是提交代码未触发Jenkins构建
认为回来200就功德圆满了，没想到仅仅是回来了200，Jenkins Job那边没有丝毫动态，也便是webhook没有触发Jenkins的履行，肯定哪里还有躲藏的坑，再次查找处理方案……
【处理办法】
URL最后要加个build，完整的形式：http://用户名:API token @IP+端口/jenkins/job/项目名称/build
坑八：Jenkins被webhook屡次无规则触发构建
在处理完坑七后，再次测验发送恳求，这次总算能够成功触发Jenkins构建了。但随之而来又遇到了匪夷所思的问题，Jenkins无端端地被屡次触发构建(企业微信收到了多封邮件)。
【问题排查】：
① 开始分析：起初我认为是不是团队中有其他人提交代码所造成的，但看了Gitlab代码提交记录，只有我一个人提交代码。
② 再次分析：或许是我同时装备了Gitlab轮询战略导致，但重新检查了一遍Jenkins Job的装备，只有Webhook一种构建触发器，且根据邮件上的构建时刻来看，几回的构建时刻距离没有任何规则，此原因也能够排除。
③ 持续分析：没过多会，”作用域“一词在我脑海中不断闪现：会不会是我创立的webhook位置创立错了，由于第一次在项目下创立时，遇到了坑一、二、三的各种报错，没有创立成功，后来在Gitlab的大局设置-Webhooks下创立成功了。此次或许和创立位置有关，也便是Gitlab的任意代码库房有代码提交，都会触发Jenkins进行构建。为了验证这种猜测，我特意问了前端的开发搭档，由于只有他们的代码是提交到Gitlab，后端是提交到SVN。果然当天下午有多位前端搭档提交代码，且提交时刻根本与我收到邮件告诉的时刻相吻合。
④ 终极验证：为了完全验证猜测，我请某位搭档再次提交了代码，果然随后Jenkins立马就被触发构建，我也收到了邮件告诉。问题总算找到了！
【处理办法】
将webhook装备在gitlab的待测验项目的代码库房下。
三、测验Webhook
提交代码，验证webhook：
Jenkins已经成功触发了构建：
四、总结与考虑
以上便是案例”运用Gitlab的webhook钩子触发Jenkins主动履行构建“的装备全进程、各种常见不常见的问题报错、处理方案，以及遇到疑难问题的排查思路，也相同适用于其他环境建立/软件工具运用/代码运转进程中的疑难问题，那便是：
- 遇到问题，先不要着急，能够先看报错信息，根据经验去处理；
- 经验处理不了，能够在网上查找其他人是否遇到过同类问题；
- 网上搜不到的，能够咨询身边有经验的搭档、朋友或同学，但问题描述需详细、切当，如问题产生的背景、前因后果，报错的信息、截图，已经尝试过的处理方法等；
- 问也问不到人的，那就只能不断尝试各种猜测，不断置疑，并且根据此种置疑去不断验证，逐个排除；
- 还有一个极为重要且有用的，便是检查该体系/软件的日志，有报错日志最好，没有报错日志就边操作复现边看日志信息；
- 不轻言放弃的精力；
我看过网上的许多教程，他们装备进程都很顺畅，三言两语就搞定了。在遇到一些疑难问题后，我也咨询过一些同行，他们都没遇到过我这么多的问题，我甚至开始置疑自己，简直是趟坑达人。不过，这也不完全是坏处，事物总有两面性，以下是一些考虑总结：
- 遇到困难不可怕，这次遇到的问题多一些，今后遇到的问题就会少一些，毕竟许多坑都已经趟过来了；
- 趟坑的目的是为了下次不再遇到坑，所谓失败乃成功之母，今后即便遇到了，也能够从容应对；
- 是问题，总会有处理办法，一时想不到，不必焦躁，不必死磕，晾一晾，转化一下思路，说不定第二天就会”山重水复疑无路，柳暗花明又一村“！
