立即登录
博客 > 术业专攻> 自动化运维> Jenkins> Jenkins实战应用–Jenkins与Gitlab分支的交互 2019年08月29日 11:26:48
文章汇总地址如右：Jenkins入门教程。
如果相中哪个，点击进去便是。希望正在读这段话的你能够在这个小系列中获得自信以及喜悦！
上次已经写过Jenkins与Git之间的一下关联，但是那篇文章阐之未尽，今天再来行文表一表Jenkins与Git分支之间的问题。
也是这中间有不少人一起探讨到关于项目分支的问题，彼时我对此没有深究，因此也是云里雾里，有人问起来，自己也是不敢确定性的告诉给人家这是什么。
这是最尴尬的事情，有些东西你以为你懂着，其实经不起别人问上一问，而显然，经不起问的，必然也就证明掌握的不够牢靠。因此，深入研究一番是自不待言的。
这也是下午做的事情。
现在，直奔主题，不说其他。
首先说Jenkins与Git分支之间的交互，有两种（当然，可能有更多，只不过我暂时掌握这两种），一种是Jenkins用Jenkins自身的构建参数来实现，另一种是通过插件来实现。
之前发布的第四篇文章（Jenkins实战应用–Jenkins一个项目的构建），因为主题是构建一个项目，分支这里也就一笔带过了，带过的连我自己也没有深入进行思考，导致不少人在配置成功之后仍旧对Jenkins是如何发布其他分支的问题抱有疑惑，今天，就来解开这个疑惑。
现在来介绍这两种交互方式。
我们来看看上次Jenkins这里是如何配置的。
今天是为了详解分支的问题，因此不计较项目的构建问题，我就在自己搭建的测试Gitlab上随便创建两个分支并写一些简单的内容，以供测试验证今天的问题。
首先来看一下这种字符参数在构建的时候是什么样的：
发布的时候，如果是默认的master分支，那么我们直接点击开始构建，就会构建master分支的代码了。
如果此时非master分支，那么删除掉Branch中的master，将要部署的分支填入点击构建就可以了。
那么这种选择分支的构建方式是怎么实现的呢？
先在参数化构建中添加字符参数：
然后注意在Git连接处填入调用分支的变量名。
很多人说填入git连接之后总是报错啊
解决办法参考Jenkins连接gitlab报错怎么办？
那么我们来看Git连接处的配置：
注意图中框起来的地方，就是上边添加字符参数时所填写的名称变量Branch。注意前边的$符号不要少了。
此时我们来做一些简单构建来看看。
构建之前我们先来看下我准备的分支以及分支下的内容：
那么我们先来构建一下master分支。
为了更清晰看到分支的变化，我们在项目的构建处添加两条命令：
现在去到项目中进行构建：
然后去看控制台的输出内容：
Started by user 李启龙
Building in workspace /root/.jenkins/workspace/test-branch
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url http://192.168.96.23/root/testa.git # timeout=10
Fetching upstream changes from http://192.168.96.23/root/testa.git
> git --version # timeout=10
using GIT_ASKPASS to set credentials
> git fetch --tags --progress http://192.168.96.23/root/testa.git +refs/heads/*:refs/remotes/origin/*
> git rev-parse origin/master^{commit} # timeout=10
Checking out Revision 2ba088747e4b0e830fef235e01c0881a62fc58b2 (origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f 2ba088747e4b0e830fef235e01c0881a62fc58b2
Commit message: "更新 readme"
> git rev-list --no-walk 2ba088747e4b0e830fef235e01c0881a62fc58b2 # timeout=10
[test-branch] $ /bin/sh -xe /usr/local/tomcat/temp/jenkins4544984219385266947.sh
+ echo /root/.jenkins/workspace/test-branch
/root/.jenkins/workspace/test-branch
+ cat readme
this is master branch
构建master分支就可以看到这句话，而且构建出来的包就是master分支。
Finished: SUCCESS
此处把构建历史单摘出来，当然意味深远，上图中我们看到构建选择master分支，那么构建的内容就是master分支下的内容。
单摘出来，就详聊一下这个日志输出的意义吧：
那么我们马上来看下构建其他分支的操作与结果。
看看结果：
此处可以看到构建了对应的分支，而且在dev分支下工作了。
不过且慢，现在猛然想起来，我们一开始提的问题好像是两次构建之间，第二次构建把第一次构建的代码怎么着了呢。
好，我想到现在去Jenkins服务器的$WORKSPACE里边看个究竟。
直接cd到刚才的构建历史输出的目录。
接下来进入一小段点评节目：
[root@xdjenkins test-branch]$cd /root/.jenkins/workspace/test-branch [root@xdjenkins test-branch]$ls readme
[root@xdjenkins test-branch]$cat readme this is dev branch 如果选择构建的是dev分支，将会看到这里的内容。
[root@xdjenkins test-branch]$git branch * (detached from cf27c4b)
[root@xdjenkins test-branch]$git branch -a * (detached from cf27c4b) remotes/origin/dev remotes/origin/liqilong remotes/origin/master
Jenkins实战应用–Jenkins构建nodejs项目 
zabbix实战应用-zabbix3.2的安装 