1，闲言碎语。

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

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

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

好了，进入正题。

这里主要展示以下内容。

• 1，模拟程序员拿到项目之后的一系列操作与使用。（即程序员与 gitlab 的交互）
• 2，配置 Jenkins 与 gitlab 的互信，然后配置自动构建。
• 3，模拟程序员开发代码，然后提交之后 Jenkins 自动构建。

需要准备的：

• 1，已经安装配置好了的 gitlab。
• 2，上篇文章中的配置好了的 Jenkins。
• 3，git 的 GUI 工具。

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

2，先在 gitlab 上操作。

1，在 gitlab 创建测试项目。

关于 gitlab 的安装这里就不展示了，不熟悉的小伙伴可以出门左转参考我发布过的 gitlab 的文章。（点击转到 gitlab 部署安装 (opens new window)）现在我们直接来到 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 的动作，具体操作如下图：

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

简单总结配置：

• 1，添加一个自由风格的名为 test 的项目。
• 2，配置 gitlab 的项目链接。
• 3，配置 gitlab 的 webhook 通过 Jenkins 的 api 进行构建。
• 4，添加构建命令以验证试验效果。

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

说明：

• 1，首先是进入到刚刚创建的 test 项目当中。
• 2，进入设置的此选项当中。
• 3，将刚才 Jenkins 中的 url 填写进来。
• 4，点击添加，就生成了。

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

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

• 1，那就是我上边再三强调的，是否一开始测试拉取分支所在的服务器目录，与刚才在项目配置处定义的目录是否一致，如果测试拉取代码是在：/usr/local/ 拉去到 test 目录中，那么再项目中就应该定义为/usr/local/test，此意为指定项目工作目录。
• 2，看看是否有一些免密码的地方配置有问题。

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 的分支提交都会触发构建。

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