1，前言

报错！是运维工作中不可豁免的一个问题。 出问题，就应是运维工作应该避免的问题。

我们有理由相信，运维的能力，就是解决问题的能力。

而有趣的是我们解决问题的能力的提升又有赖于问题的解决，如果平常连问题都无从解决，那么也毋谈能力的提升了。

我想到自己遇到问题的时各方求索无果的时候，一方面想骂一句网上的教程都是坑，但是到最后自己的答案还是需要去网上来找。事实就是如此荒唐。不知道别人提倡的理念是什么，总之我觉得，遇到问题，一定要去请教，如果自己死扣，浪费时间不说，还做了很多无用功，请教之后学会了，记住了，就变成自己的了。

鉴于此，个人打算专门开一篇文章收录Jenkins使用过程中遇到的报错，异常，问题等。

简单说明：

1，收集的问题皆是我所见到的，以及我所解决的。

说白了就是每个人遇到的问题可能不同，或者遇到同一个问题的原因也可能是不同的，那么我这里所给出的解决办法可能只适用于我所遇到的情况，不一定具有万能性。

2，我会尽量将问题重现，说明，解决。

我会尽自己能尽量将问题重现一下，把出现此问题的可能性给出来，解决的思路以及办法也都毫不保留的倾囊相述，如果那些地方是有毛病的，欢迎评论区指出，让此文章真正成为一个可以帮人解决燃眉之急的“及时雨”。

3，如果有问题，可与我联系。

每个人都是在不断学习当中成长的，我也一样，如果在某些地方有疑问，或者搞不懂，欢迎通过主页的qq或者微信与我联系。

4，本文会持续性更新。

本文将会在相当长的一段时间里，不断更新与补充，尽量将其完善成为一个问题解决小手册。

很早前，我每天都被深刻灌输以及践行“帮助别人，成就自己”的口号。现在，这句话仍旧被我传承发扬着。

技术人有一个很奇怪的癖好就是“敝帚自珍”（讽刺之意），总愿意把自己的那些或是很差的或是很好的东西保存，收藏，自用。这是一种很奇怪的癖好，一点也不好。

ok，接下来，开始表演。

表演之前仍旧先来个小福利缓解一下因为报错而受扰的心情。

2，忘记管理员密码怎么办。

平常我们都是通过普通用户来对Jenkins进行管理，配置，发布等操作，但是如果某天需要管理员的用户密码，而这个大家并不常用的密码，也就被遗忘到了九霄云外，这个时候该怎么办呢，有两种办法可以找回。

具体操作参考我的另外一篇，Jenkins忘记管理员密码怎么办。Jenkins实战应用–Jenkins忘记管理员密码怎么办 (opens new window)。

3，配置Git连接时报错怎么办。

有不少人在刚开始入门Jenkins的时候都会遇到与Git连接的问题，其实这里的问题并不复杂，只不过对其两者之间的关系不大清晰，因此才觉得一头雾水。

报错内容无非如下两种：

1，URL开头是http的报错。

Failed to connect to repository : Command “git ls-remote -h http://192.168.96.23/root/testa.git HEAD” returned status code 128:
stdout:
stderr: error: The requested URL returned error: 401 Unauthorized while accessing http://192.168.96.23/root/testa.git/info/refs



fatal: HTTP request failed

2，URL开头是git的报错。

Failed to connect to repository : Command “git ls-remote -h [git@192.168.96.23](mailto:git@192.168.96.23):root/testa.git HEAD” returned status code 128:
stdout:
stderr: Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
fatal: The remote end hung up unexpectedly

如下图：

如果你确确实实是第一次刚刚把主机初始化进入到Jenkins，然后配置了一个项目，配置完Git连接就见红报错了。那么这个时候你应该检查一下，是不是你的主机没有安装git的命令。使用yum -y install git即可解决。

之前有人在群里发过碰到这个错误怎么办，我当时因为理解不透，而且看到自己这边配置的地址是git@192.168.96.23:root/testa.git一直是成功的，因此就帮人指导说你换成git开头的URL就好了，熟不知问题的症结压根就不在这里，而是因为没有配置秘钥认证才导致的见红（报错）。

不过即便不是哪个开头的问题，我也推荐使用git开头的URL作为项目链接填写在这里，因为下午看廖雪峰Git教程时看到其中有这么说：使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

因此，如果条件允许，那么我推荐使用git开头的url，如果公司禁止22端口，那么再选择其他。

现在说回刚才的问题。其实解决起来也非常简单。

不过此处也话分两头。

1，如果填写的url是刚才的http开头的。

那么此时点击红色提示下边的add添加可以登录到gitlab上并且对项目有权限的用户。

如我刚搭建的gitlab，账号还是默认的管理员root，如下将账号密码填写进去，点击add添加。

然后选择用户中，选中刚才添加的root账户。

此时就会发现，红色报错消失了，表明Jenkins与gitlab的连接通了。

2，如果刚刚填写的url是git开头的。

此时只用去到Jenkins服务器上，将其公钥放在gitlab的ssh key处，红色报错就消失了。

ssh-keygen	#一路回车
cat /root/.ssh/id_rsa.pub  #复制下来

1，点击头像选中设置。

2，点击ssh秘钥栏。

3，在此处将刚才复制的秘钥拷贝进来。

再回到Jenkins当中查看，发现报错也消失了。一旦这种互信创建完成之后，基本上两者就默认对上号了。

如果配置完了之后还不成功，而且报128的错误码，那么应该是在第一次建立互信的时候需要输入一下yes的问题，去Jenkins主机上，手动建立一次与gitlab的连接即可（建立ssh的连接或者git的连接都可以）。

其实上边刚才有两个地方的表述，是不严谨的，分别是1，2标题处我说当url的开头是什么什么，当时这么说只是为了让ssh与秘钥对应，http与用户名对应而已，事实上，只要配置了其中一种互信方式，那么无论url的开头是http还是git，都是可以连接的。

补充：

如果刚才add账户的时候错了，该怎么办呢？

去到首页—>点击Credentials就能看到自己添加过的用户，并进行管理了。

4，部署失败之ERROR: Couldn’t find any revision to build. Verify the repository and branch configuration for this job

当我们开发人员来找到我们说，我刚刚构建失败啦。

然后你去看到底什么问题。

ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

看到这样的问题，那么基本可以断定，应该是他刚刚新建了一个分支，要进行测试构建，但是可能代码还没有push到远端代码库，而在构建的时候又填写了这个分支，那么Jenkins就会报错：ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.（找不到任何修订版本。 验证此作业的存储库和分支配置--谷歌翻译）

就让他重新push之后在构建咯。这个问题可以通过构建一个不存在的分支进行复现测试。

5，部署之后代码没有改变的问题

最近两周新上项目较多，因此我与另外一位运维小伙伴两个人一起扛起了许多项目的交付与上线。

但是今天突然一个小伙伴跟我说，部署了之后发现代码没有变化。一开始我以为是Jenkins与Gitlab之间的问题，导致的代码更新问题。

后来跑到他身边，经过他那么一演示，我明白了。并根据经验解决了这次问题。

他给我演示的是原来代码里引用了某个类，现在呢，是把这个类给删除了，但是推了代码，重新发布，去看程序日志输出发现刚才删除的类，现在还在呢。

我就想应该是发布的时候没有清掉，估计就是mvn打包时候的问题啦，到Jenkins的配置里边一看，果然，只有正常打包的命令，而少了一个clean的参数，从而使得这个程序的打包命令只会一直往前打包，也就是说代码里有新的依赖等的他会解决加进来，但是如果删掉了某个类或者依赖，他则不会做任何动作。

加上clean的参数，事实上就是首先将其清空，然后再来依据代码里边的pom文件或者其他装载着依赖的文件进行打包构建。于是，问题就解决啦！

更新之后的打包命令如下：

mvn clean install -Dmaven.test.skip=true

6，Jenkins与tomcat在同一台部署完毕进程被kill的问题

如果Jenkins与tomcat在同一台当中部署，这个时候部署项目的时候，发现部署完毕之后项目进程会被干掉。

问题过程大概是这样，当用户发起构建，系统当中会启动相应的进程进行构建任务，当构建任务完成之后，或者被人为中断之后，程序利用ProcessTreeKiller，获取计算机上运行的所有进程及其环境变量的列表，并查找最初为构建作业的进程设置的环境变量，然后终止在其环境中具有该环境变量的每个作业。

解决思路：实现这一目标的一种便捷方法是更改Jenkins的ProcessTreeKiller正在寻找的环境变量BUILD_ID，这将会让Jenkins认为您的守护进程不是由Jenkins构建生成的。

比如在执行shell当中添加如下变量即可：

BUILD_ID=dontKillMe
注意：如果Jenkins Pipeline使用JENKINS_NODE_COOKIE而不是BUILD_ID。

参考：https://wiki.jenkins.io/display/JENKINS/ProcessTreeKiller