2，忘记管理员密码怎么办。
平常我们都是通过普通用户来对Jenkins进行管理，配置，发布等操作，但是如果某天需要管理员的用户密码，而这个大家并不常用的密码，也就被遗忘到了九霄云外，这个时候该怎么办呢，有两种办法可以找回。
具体操作参考我的另外一篇，Jenkins忘记管理员密码怎么办。Jenkins实战应用–Jenkins忘记管理员密码怎么办 。
#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
3
4
5
6
7
2，URL开头是git的报错。
Failed to connect to repository : Command “git ls-remote -h [[email protected]](mailto:[email protected]):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
2
3
4
5
6
如下图：
如果你确确实实是第一次刚刚把主机初始化进入到Jenkins，然后配置了一个项目，配置完Git连接就见红报错了。那么这个时候你应该检查一下，是不是你的主机没有安装
git的命令。使用yum -y install git即可解决。
之前有人在群里发过碰到这个错误怎么办，我当时因为理解不透，而且看到自己这边配置的地址是[email protected]: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 #复制下来
2
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。