*系列汇总*
文章汇总地址如右: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 是根据分支进行拉取。
4,ok,现在我们去创建一个项目进行测试。
来到Jenkins的配置界面。
1,先添加这样一个ssh server。
进入系统管理—》系统设置。
如果测试中报错: 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方。点击系统设置—》全局安全配置—》取消“防止跨站点请求伪造”—》配置授权“授权策略”中的“安全矩阵”。
接着:
配置完之后保存,然后再重复刚才在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的分支提交都会触发构建。
嗯,这个知识点就分享到这里,如果有一些其他的个性化需求,请根据这些现有的功能,发挥自己的脑洞,灵活运用。