• 对于注定会优秀的人来说,他所需要的,只是时间----博主
  • 手懒得,必受贫穷,手勤的,必得富足----《圣经》
  • 帮助别人,成就自己。愿君在本站能真正有所收获!
  • 如果你在本站中发现任何问题,欢迎留言指正!
  • 宝剑锋从磨砺出,梅花香自苦寒来!
  • 本站开启了防爆破关小黑屋机制,如果您是正常登录但被关进小黑屋,请联系站长解除!

<十六>Jenkins实战应用–Jenkins与Gitlab分支的交互

Jenkins eryajf 1年前 (2018-05-22) 4312°C 已收录 2个评论
本文预计阅读时间 15 分钟

*系列汇总*

这是一个系列文章,大大小小到今天惊然发现竟然已经累计二十篇了,也就不得不做一个小汇总。回想当初写第一篇文章的时候,就已经决心事无巨细,一应认真的走下来,回头遮望,看着皇皇这么多文章,一股强烈的成就感就此油然而生,于是便有了这些汇总整理。在这个过程当中,好像也帮助过不少的人,这是让我尤其开心的事情,同时也结识了一些志同道合的朋友,再没有比这更让人觉得愉悦的事情啦!也希望以后写出更多类似的系列文章。

文章汇总地址如右:Jenkins入门教程。

如果相中哪个,点击进去便是。希望正在读这段话的你能够在这个小系列中获得自信以及喜悦!

上次已经写过Jenkins与Git之间的一下关联,但是那篇文章阐之未尽,今天再来行文表一表Jenkins与Git分支之间的问题。

也是这中间有不少人一起探讨到关于项目分支的问题,彼时我对此没有深究,因此也是云里雾里,有人问起来,自己也是不敢确定性的告诉给人家这是什么。

这是最尴尬的事情,有些东西你以为你懂着,其实经不起别人问上一问,而显然,经不起问的,必然也就证明掌握的不够牢靠。因此,深入研究一番是自不待言的。

这也是下午做的事情。

  • 1,在自己本地搭建了一个gitlab服务器,不仅仅为了这次测试,也为了以后各种倒腾之需。
  • 2,顺道模拟开发学习了一波Git的使用。
  • 3,验证以及总结Jenkins与Git分支之间的一些交互问题。
  • 现在,直奔主题,不说其他。

    首先说Jenkins与Git分支之间的交互,有两种(当然,可能有更多,只不过我暂时掌握这两种),一种是Jenkins用Jenkins自身的构建参数来实现,另一种是通过插件来实现。

    之前发布的第四篇文章(Jenkins实战应用–Jenkins一个项目的构建),因为主题是构建一个项目,分支这里也就一笔带过了,带过的连我自己也没有深入进行思考,导致不少人在配置成功之后仍旧对Jenkins是如何发布其他分支的问题抱有疑惑,今天,就来解开这个疑惑。

    现在来介绍这两种交互方式。

    1,通过构建参数中的字符参数来实现。

    我们来看看上次Jenkins这里是如何配置的。

    今天是为了详解分支的问题,因此不计较项目的构建问题,我就在自己搭建的测试Gitlab上随便创建两个分支并写一些简单的内容,以供测试验证今天的问题。

    首先来看一下这种字符参数在构建的时候是什么样的:

    发布的时候,如果是默认的master分支,那么我们直接点击开始构建,就会构建master分支的代码了。

    如果此时非master分支,那么删除掉Branch中的master,将要部署的分支填入点击构建就可以了。

    那么这种选择分支的构建方式是怎么实现的呢?

    先在参数化构建中添加字符参数:

    然后注意在Git连接处填入调用分支的变量名。

    很多人说填入git连接之后总是报错啊

    解决办法参考Jenkins连接gitlab报错怎么办?

    那么我们来看Git连接处的配置:

    注意图中框起来的地方,就是上边添加字符参数时所填写的名称变量Branch。注意前边的$符号不要少了。

    此时我们来做一些简单构建来看看。

    构建之前我们先来看下我准备的分支以及分支下的内容:

    1,这是master分支。

    2,这是dev分支。

    3,这是liqilong分支。

    那么我们先来构建一下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分支下的内容。

    单摘出来,就详聊一下这个日志输出的意义吧:

    1,表示项目构建人事李启龙。
    2,表示在此目录下进行的构建。
    从第三行到第十五行都是对git的连接与操作,这里捡一些重要的来讲一下(其实是捡我知道的来讲下,不知道的也没法讲呀)。
    4,从远程Git仓库读取更改。
    10,表示本地构建的分支是master分支。
    11,显示出本地构建的commit id.
    13,根据commit id切换到对应的分支。
    14,本地构建的commit message。
    16,Jenkins临时生成一个构建脚本进行构建。
    17,是打印我刚才的第一条命令。
    18,是第一条命令的结果输出。
    19,打印第二条命令。
    20~22,第二条命令结果输出。
    23,构建结果,成功。

    那么我们马上来看下构建其他分支的操作与结果。

    看看结果:

    此处可以看到构建了对应的分支,而且在dev分支下工作了。

    不过且慢,现在猛然想起来,我们一开始提的问题好像是两次构建之间,第二次构建把第一次构建的代码怎么着了呢。

    好,我想到现在去Jenkins服务器的$WORKSPACE里边看个究竟。

    直接cd到刚才的构建历史输出的目录。

    接下来进入一小段点评节目:

    [root@xdjenkins test-branch]$cd /root/.jenkins/workspace/test-branch  
    [root@xdjenkins test-branch]$ls
    readme		
    
    评上:ok,果然只有readme一个人。
    [root@xdjenkins test-branch]$cat readme
    this is dev branch
    
    如果选择构建的是dev分支,将会看到这里的内容。
    
    评上:内容也是dev的东东,而关于刚刚构建的master的,已经消失不见。
    [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
    
    评上:略知一二了。
    [root@xdjenkins test-branch]$git log
    commit cf27c4b0f1f8ef8c5849cec63bf93bd1d0328e98
    Author: Administrator <admin@example.com>
    Date:   Tue May 22 19:06:16 2018 +0800
    
        更新 readme
    
    commit 7179bb71ae6601154648e2d979b1474e2467dd38
    Author: eryajf <Linuxlql@163.com>
    Date:   Tue May 22 16:47:35 2018 +0800
    
        添加文件
    
    commit 4c15546cc08c146d63c4f3ada647b4f0068928fb
    Author: eryajf <Linuxlql@163.com>
    Date:   Tue May 22 16:45:31 2018 +0800
    
        测试提交
    
    评上:搜嘎,commit id对着嘞。
    [root@xdjenkins test-branch]$git show cf27c4b0f1f8e
    commit cf27c4b0f1f8ef8c5849cec63bf93bd1d0328e98
    Author: Administrator <admin@example.com>
    Date:   Tue May 22 19:06:16 2018 +0800
    
        更新 readme
    
    diff --git a/readme b/readme
    index 64fdb4f..5e4f328 100644
    --- a/readme
    +++ b/readme
    @@ -1,3 +1,3 @@
     this is dev branch
    
    -这次修改是为了验证新分支开发后提交。
    +如果选择构建的是dev分支,将会看到这里的内容。
    
    评上:行啦,知道你是什么情况啦。

    那么现在可以纠正一下刚才的一个错误,刚才说第二次构建就是在dev分支下工作了,而经过上边这波操作之后发现,事实并非如此,Jenkins是将dev分支上最新的那次commit id作为临时工作“分支”,从而保证代码的新鲜度。

    哎呀,一下没收住,打破砂锅问到底的精神又冒出来了,可能有人觉得跑这么深没什么必要,但是因为有了这次没必要的深入,至少以后在遇到构建失败或者异常等问题时,知道在$WORKSPACE这里究竟曾发生过什么事儿。

    好了,问题找到答案了,现在去将第二种分支构建的方式完善了吧。

    2,通过Git Parameter插件实现选择分支进行构建。

    同样,先来看下这种方式的构建方式是怎样的:

    可以看到方框中直接把我项目的分支罗列了出来。构建的时候直接选择分支,然后进行构建就ok了。

    那么这种方式是如何实现的呢?

    首先去安装插件:Git Parameter ,就不过多废话了。

    接着看图学技能:

    通过插件中的配置,来实现构建时分支的选择。

    简单测试一下,看看其效果:

    在构建中选择哪个没有构建过的分支:

    然后看一些构建日志:

    与第一种构建方式如出一辙。

    尾巴!

    或许我们掌握一种方式能够成功就足够了
    甚至我们都不需要知道它是怎么成功的
    或者我们掌握多种方法把一件事儿完成
    在掌握一种方式之外的那种方式的过程中
    就已经对这个环节,了如指掌以至于用起来得心应手!

    weinxin
    扫码订阅,第一时间获得更新
    微信扫码二维码,订阅我们网站的动态,另外不定时发送WordPress小技巧,你可以随时退订,欢迎订阅哦~

    二丫讲梵 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明<十六>Jenkins实战应用–Jenkins与Gitlab分支的交互
    喜欢 (5)
    [如果想支持本站,可支付宝赞助]
    分享 (0)
    eryajf
    关于作者:
    学无止境,我愿意无止境学。书山有路,我愿意举身投火,淬炼成金!

    您必须 登录 才能发表评论!

    (2)个小伙伴在吐槽