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

<十九>Jenkins实战应用–配置gitlab提交代码Jenkins自动构建

Jenkins eryajf 1年前 (2018-06-04) 4475°C 已收录 2个评论
本文预计阅读时间 21 分钟

*系列汇总*

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

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

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

本文整理自网上飞翔大神分享的文章。

1,闲言碎语。

承接上一篇文档以及在上篇所配置好的环境,继续往前走,模拟开发提交代码之后,Jenkins自动构建的试验。

之前从来没有做过自动构建的事情,有时候听着别人说如何如何,开发提交之后就构建了,好像很不一般。

自己知道是如何实现的,但是总觉得好像有局限,就没有前去涉猎,但是今天根据教程看了之后,发现有些事情呀,或者有些偏见呀,都是来自于一些小的,基础的不能在基础的东西。因为你不懂某个小基础,那么,可能蝴蝶效应的,后续很多东西你也就无从知起。

好了,进入正题。

这里主要展示以下内容。

需要准备的:

现在进入正题。因为试验已经根据飞翔文档做过一遍了,所以现在整理的话,就不再看文档了,根据自己的记忆,来完成整个的配置。

2,先在gitlab上操作。

1,在gitlab创建测试项目。

关于gitlab的安装这里就不展示了,不熟悉的小伙伴可以出门左转参考我发布过的gitlab的文章。(点击转到gitlab部署安装)现在我们直接来到Windows的git客户端。

Administrator@liqilong MINGW64 ~/Desktop/gittest
$ git clone git@192.168.106.70:linux/test.git
Cloning into 'test'...
warning: You appear to have cloned an empty repository.

Administrator@liqilong MINGW64 ~/Desktop/gittest
$ cd test

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master)
$ echo "this is master branch." > readme

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master)
$ cat readme
this is master branch.

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master)
$ git add readme

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master)
$ git commit -m 'add readme'
[master (root-commit) bf79505] add readme
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 readme

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master)
$ git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 204 bytes | 204.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To 192.168.106.70:linux/test.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

然后去gitlab中就能看到刚才创建的项目已经有内容了。

接着再来创建一个分支作为开发分支。再来一波操作。

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master)
$ git branch dev

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master)
$ git checkout dev
Switched to branch 'dev'

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev)
$ ls
readme

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev)
$ echo "this is dev branch" > readme

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev)
$ cat readme
this is dev branch

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev)
$ git commit -a -m 'add dev'
warning: LF will be replaced by CRLF in readme.
The file will have its original line endings in your working directory.
[dev 8419ae8] add dev
 1 file changed, 1 insertion(+), 1 deletion(-)

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev)
$ git push origin dev
Counting objects: 3, done.
Writing objects: 100% (3/3), 248 bytes | 248.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: To create a merge request for dev, visit:
remote:   http://192.168.106.70/linux/test/merge_requests/new?merge_request%5Bsource_branch%5D=dev
remote:
To 192.168.106.70:linux/test.git
 * [new branch]      dev -> dev

然后去gitlab就能看到dev分支以及对应内容了。

3,将Jenkins的公钥放入gitlab中,测试是否可以进行拉取代码。

假定我们的项目目录是宿主机的/usr/local/test目录。

[root@localhost test]$cd /usr/local/
[root@localhost test]$git clone -b dev git@192.168.106.70:linux/test.git
Cloning into 'test'...
remote: Counting objects: 9, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 9 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (9/9), done.
[root@localhost test]$ls
test
[root@localhost test]$cd test/
[root@localhost test]$ls
readme
[root@localhost test]$cat readme
this is dev branch

说明: -b 是根据分支进行拉取。
注意:如果拉取失败,有可能是秘钥配置问题,可以将Jenkins本机秘钥删除,然后再次生成添加,就可以了。

4,ok,现在我们去创建一个项目进行测试。

来到Jenkins的配置界面。

1,先添加这样一个ssh server。

注意这里添加的远程工作目录要与我们刚才测试拉取的目录保持一致,以使其工作的时候,可以直接通过Git进行连接,配置,这一点至关重要,不然稍候配置完成之后,就会出现构建异常的问题。我刚才就掉进这个坑里了,现在找到了是这个原因,然后回头一想,不禁拍腿叹息,哎呀,,这里其实就是模仿的正常的,就像我们开发工作一样的,在某个目录,拉取代码,进行开发,推拉弹唱,都是在这个目录下进行,然后Jenkins就是一个自动化的外壳,,完全套进去,然后进行工作。

进入系统管理—》系统设置

如果测试中报错: jenkins.plugins.publish_over.BapPublisherException: Failed to connect and initialize SSH connection. Message: [Failed to change to remote directory [/usr/local/test]]

看信息得知是没有这个目录,去服务器创建一下就好了。

然后新建项目,创建一个自由风格的名为test的项目,分支填写成dev,从而在构建的时候直接默认为dev分支。

接着配置构建触发器。

在构建中添加ssh server的动作,具体操作如下图:

暂时这样一个简答的项目就创建完成了。

简单总结配置:

5,将刚才的Jenkins api添加到gitlab中。

说明:

那么现在就在gitlab这里先测试下效果,看看点击这里之后,Jenkins是否会自动构建。注意,我们现在的项目可是刚创建好,现在先去跑一下看看效果如何。

这里是我们的第一次构建,如果你跟着做的,但是构建失败或者异常,那么有以下思路可供参考:

6,试验。

那么接下来,我们一层一层剥离,先看在gitlab中手动一下看看是否能联动Jenkins的构建。

方法很简单,在前边配置好的webhook当中点击Push Events.

点击之后,我们去看下Jenkins那边是什么效果。

哎呦我去,报错了!!

看到403的错误应该是刚刚添加的URL访问出问题啦。而,前人存在的意义正在于,把这些小坑填平助我们直驱成功。

注意:如果你此刻做测试所使用的Jenkins是公司生成在用的,而且这个Jenkins也启用了相关的针对不同用户分配不同视图的功能了的话,那么,请谨慎执行下边的操作,因为下边的操作可能会导致你之前做过的权限分配,化为虚有,当然,如果你用的Jenkins是自己个人测试的,或者压根就没有启用用户权限分配相关的功能,那么可以大胆的往下走。

现在去到Jenkins方。点击系统设置—》全局安全配置—》取消“防止跨站点请求伪造”—》配置授权“授权策略”中的“安全矩阵”。

接着:

配置完之后保存,然后再重复刚才在gitlab当中的动作。

看到了返回值至少已经是200了。如下图:

接着去Jenkins中看看。

再看下构建信息:

完美。如果已经到了这步,那么接下来你就可以安心于开发了,从你开发中,无论开发了什么代码,只要一进行提交,那么就会触发Jenkins的构建,新代码也就自动跑到远程目标服务器啦。

接下来先模拟一下开发与提交:

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev)
$ ls
readme

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev)
$ echo "Test push code builds automatically" >> readme

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev)
$ cat readme
this is dev branch
Test push code builds automatically

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev)
$ git commit -a -m "Test push code builds automatically"
warning: LF will be replaced by CRLF in readme.
The file will have its original line endings in your working directory.
[dev 0cd5af4] Test push code builds automatically
 1 file changed, 1 insertion(+)

Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev)
$ git push origin dev
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 309 bytes | 309.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: To create a merge request for dev, visit:
remote:   http://192.168.106.70/linux/test/merge_requests/new?merge_request%5Bsource_branch%5D=dev
remote:
To 192.168.106.70:linux/test.git
   8419ae8..0cd5af4  dev -> dev

now,去看下Jenkins是否执行了构建并把新代码推到了远程服务器。

然后看代码是否是新的。

此处模拟的算是一个类似php或者静态网站开发的一系列自动化,那么,套用这个思路,基本上对于java项目,nodejs项目,以及其他项目,都是可以通过这种方式来进行配置构建的。

以上的试验流程,是依据原文进行了一次疏通与整理,并没有再往深入的探索以及应用,因为在我们公司里边,并没有任何一个项目,是使用了自动构建的这种方式的,当然了,每家有每家的情况,要能够结合实际工作情况,来进行分析判断。

7,补充内容,分支的探索。

昨天收到一个同学的求助,说自己公司的情况正是如此,测试预发线上三个环境全部都在一个Jenkins中,然后测试以及预发的项目都做成了自动构建的,现在的问题是,在测试提交代码,会发现,测试以及预发的这个项目都构建起来了。那么问题来了,如何实现,提交对应的环境的代码,就只有对应环境的项目部署?

首先,听完这段话,我想说,首先三个环境放在一起,不合理,测试可以自动构建,预发,不应该自动构建了,最后他的回答是,这些功能是之前的运维人员配置的,现在也没有太多话语权,无法决定大建筑上的东东。

唯有提升自己的技术,才是最真的王道!

那么好,现在就来说说这个自动构建过程中如何让项目区分开来。当然,可能像这样测试预发放在一起,又同时开启了自动构建的情况,并不常见,但是,经过对接下来这个知识点的了解学习,可以让我们掌握,如何在配置自动构建的时候,灵活的控制分支问题。

其实,玄机就在Jenkins项目配置当中webhook处的高级里边的内容,下图是展开的高级的样子:

这个地方Jenkins默认的选择的是接受所有分支提交的触发,也就是,无论你提交了什么分支,那么都会触发此项目的构建。

现在,假如我们开发的分支都是dev分支,那么可以如下图设置:

这样配置之后,即代表此项目只在当dev分支提交会触发构建,其他分支提交则不会触发构建。

当然这个地方可以使用通配符进行扩展性定义:

  • *.dev : 表示以dev结尾的分支提交都会触发构建。
  • dev.* : 表示以dev开头的分支提交都会触发构建。
  • *.dev.* : 表示包含dev的分支提交都会触发构建。

嗯,这个知识点就分享到这里,如果有一些其他的个性化需求,请根据这些现有的功能,发挥自己的脑洞,灵活运用。


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

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

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

(2)个小伙伴在吐槽
  1. 博主你好,这个apk的功能不是所有版本的jenkins镜像都有的,这一点你没有说明,我从官网安装的jenkins不具有此功能。查了一下,只有以alpine为基础镜像的才有
    1660713893@qq.com2019-03-31 09:15 Windows 7 | Chrome 72.0.3626.119
    • eryajf
      是的,还是要看基础镜像是什么,如果基础镜像是alpine,那么包管理工具就是apk的。另外一方面,在企业当中,事实上并不十分建议将Jenkins容器化的,当然,这些可以根据自己的需求来进行安排。
      eryajf2019-03-31 10:22 Windows 7 | Chrome 70.0.3538.9