GitLab 自动触发 Jenkins 构建

GitLab 自动触发 Jenkins 构建

在 Jenkins 中安装插件

选择 系统管理 -> 管理插件 打开插件管理也页面，以下图：

在 可选插件 中选择 Gitlab Hook Plugin 和 GitLab Plugin 等插件，而后点击下方的 直接安装 按钮安装插件：

 

 

建立测试工程

 

为了便于测试，这里分别先在 Jenkins 和 GitLab 上建立测试工程。在 Jenkins Dashboard 主页点击 新建任务，进入新建任务页面：

 

 

 

在输入框中输入工程名，选择 构建一个自由风格的软件项目，而后点击左下角的 肯定按钮，进入工程配置页面。

 

在工程配置页面的 源码管理部分，输入 GitLab repo 的 URL，以下图：

 

 

 

若是是 https 形式的 URL，记得配置登陆 GitLab 的用户名和密码，经过点击 Credentials 行最后面的 Add -> Jenkins 按钮，在弹出的以下对话框中输入用户名和密码：

 

 

Add 以后，在 Credentials 的下拉框中选择这组用户名和密码。没有添加 GitLab 的用户密码的话，Jenkins 报错 —— 没法访问 repo，以下图：

 

 

 

随后点击左下角的 保存 按钮，完成 Jenkins 工程的建立，并将它与 GitLab 的工程关联起来。

 

配置 GitLab 用户

 

建立一个用户或选择一个已有用户，用来让 Jenkins 和 GitLab API 交互。这个用户将须要是全局的管理员或添加进每一个组／工程，并做为成员。须要开发者权限来报告构建状态。这是因为，当使用了 'Merge when pipeline succeeds' 功能时，成功的构建状态能够触发合并。GitLab Plugin 的一些功能可能须要其它的一些权限。好比，有一个选项用于在构建成功时，接受 merge request。使用这一功能须要 developer，master 或 owner 级的权限。

 

选择 Settings -> Account：

 

 

 

拷贝其中的 Private token，稍后在配置 Jenkins 服务器时会用到。

 

配置 Jenkins 服务器

 

须要配置 Jenkins 服务器来与 GitLab 服务器通讯。

 

在 Jenkins 中，选择 系统管理 -> 系统设置，在系统设置中找到 GitLab 的部分：

 

 

 

在 Connection name 后的输入框中输入链接名称，在 Gitlab host URL 后的输入框中输入 GitLab 服务器的 URL 地址。点击 Credentials 行最后面的 Add -> Jenkins 按钮，弹出以下对话框，在Kind 后的下拉列表中选择 GitLab API token，并把上一步拷贝的 Private token 粘贴到 API token后面的输入框中。随后在 Credentials 的下拉框中选择 GitLab API token。

 

配置 Jenkins 工程

 

打开 Jenkins 工程的配置页面，找到 构建触发器 的部分，勾选 Build when a change is pushed to GitLab 那一行：

须要记下 Build when a change is pushed to GitLab 那一行中，GitLab CI Service URL: 后面的 URL，后面在配置 GitLab 工程时须要用到。

 

还要点开右下角的 高级：

 

 

 

随后点击右下角的 Generate 按钮，生成 Secret token，保存这里生成的 Secret token，它一样将用于后面 GitLab 的配置。随后点击左下角的 保存 按钮，保存前面所作的配置。

 

配置 GitLab 工程

 

建立一个新的或选择一个已有的 GitLab 工程。而后选择 Settings -> Integrations，在 URL 一栏中输入前面保存的 GitLab CI Service URL，在 Secret Token 一栏中输入前面保存的 Secret token，而后选择须要 trigger Jenkins 工程执行构建的事件：

 

 

 

点击绿色的 Add webhook 按钮，完成 webhook 的建立。

 

建立好了 webhook 以后，点击 Test 下拉框中的 Push events，以下图：

 

 

 

能够手动产生事件，触发 Jenkins 工程。点击 Edit，在 webhook 的编辑页面，拉到页面底部，还能够看到，该 webhook 最近的调用状况，以下图：

 

 

 

点开特定调用的 View details，还能够看到此次调用的详细状况，以下图：

由此不难理解，GitLab trigger Jenkins 工程，主要是经过向 Jenkins 服务器发送一个 POST 请求实现的。

 

验证测试

 

修改咱们的 GitLab 测试工程中的文件，并 push 到 GitLab 服务器上：

 

➜  test_for_gerrit git:(master) echo "Hello, world" >> read2.md

➜  test_for_gerrit git:(master) ✗ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)    modified:   read2.mdno changes added to commit (use "git add" and/or "git commit -a")
➜  test_for_gerrit git:(master) ✗ git add .
➜  test_for_gerrit git:(master) ✗ git commit -m "Add test data."➜  test_for_gerrit git:(master) git pushwarning: push.default is unset; its implicit value has changed inGit 2.0 from 'matching' to 'simple'. To squelch this messageand maintain the traditional behavior, use:

  git config --global push.default matching

To squelch this message and adopt the new behavior now, use:

  git config --global push.default simple

When push.default is set to 'matching', git will push local branches
to the remote branches that already exist with the same name.

Since Git 2.0, Git defaults to the more conservative 'simple'behavior, which only pushes the current branch to the corresponding
remote branch that 'git pull' uses to update the current branch.

See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode'current' instead of 'simple' if you sometimes use older versions of Git)

Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 312 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To ssh://git@g.hz.netease.com:22222/cloudgame/test_for_gerrit.git   23660c1..e86152a  master -> master
➜  test_for_gerrit git:(master)

 

随后迅速地就能在 Jenkins 中，测试工程主页面的左下方，看到由 GitLab push 所 trigger 起来的构建任务：

在由 GitLab push 所 trigger 起来的构建任务的下方，会显示构建任务是由谁 push 的代码所 trigger 起来的。打开特定构建任务的 控制台输出 能够看到构建的详细过程：