*系列汇总*
文章汇总地址如右：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 的分支提交都会触发构建。
嗯，这个知识点就分享到这里，如果有一些其他的个性化需求，请根据这些现有的功能，发挥自己的脑洞，灵活运用。
