背景
我经常写测试——这算是我对软件工程的一点执念。前阵子折腾了基于ZStack的二次开发，每次提交代码前都要自己跑一趟测试，着实有点慢。自己撸一套系统成本又太高，正发愁时发现GitLab自带了CI系统，便开始了折腾之旅。
概念
CI(Continuous Integration)
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
GitLab-Runner
类似于工人的概念。如果我们需要CI能够工作，我们至少需要一个Runner。同时，在一台机器上可以安装多个Runner。另说一句，如果有隔离环境的需求，Vm和Docker几乎是最佳选择。
类型
GitLab-Runner被分为两种类型：Shared Runner（共享）和Specific Runner（特定）。
Shared Runner：所有工程都够共用——只有系统管理员能够创建Shared Runner。
Specific Runner：只能为指定的工程服务——拥有该工程访问权限的人都能够为该工程创建Shared Runner。
Pipelines
翻译成流水线是比较恰当的。通过定义项目中的.gitlab-ci.yml我们可以定义一条流水线会有哪几个stage（阶段）。比如编译->测试->部署等。
一个Runner同时可以执行多个Pipelines。
尝试工作
首先来到项目的主页，我们可以看到设置CI
点击后，可以看到这样的界面
Template根据项目自行选择。我的项目是Java的，并且使用了Maven，因此选择Maven
GitLab将会提供你一份含有详细注解的模板文件：
# This file is a template, and might need editing before it works on your project.
---
# Build JAVA applications using Apache Maven (http://maven.apache.org)
# For docker image tags see https://hub.docker.com/_/maven/
#
# For general lifecycle information see https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
#
# This template will build and test your projects as well as create the documentation.
#
# * Caches downloaded dependencies and plugins between invocation.
# * Verify but don't deploy merge requests.
# * Deploy built artifacts from master branch only.
# * Shows how to use multiple jobs in test stage for verifying functionality
# with multiple JDKs.
# * Uses site:stage to collect the documentation for multi-module projects.
# * Publishes the documentation for `master` branch.
variables:
# This will supress any download for dependencies and plugins or upload messages which would clutter the console log.
# `showDateTime` will show the passed time in milliseconds. You need to specify `--batch-mode` to make this work.
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN -Dorg.slf4j.simpleLogger.showDateTime=true -Djava.awt.headless=true"
# As of Maven 3.3.0 instead of this you may define these options in `.mvn/maven.config` so the same config is used
# when running from the command line.
# `installAtEnd` and `deployAtEnd` are only effective with recent version of the corresponding plugins.
MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true"
# Cache downloaded dependencies and plugins between builds.
# To keep cache across branches add 'key: "$CI_JOB_REF_NAME"'
cache:
paths:
- .m2/repository
# This will only validate and compile stuff and run e.g. maven-enforcer-plugin.
# Because some enforcer rules might check dependency convergence and class duplications
# we use `test-compile` here instead of `validate`, so the correct classpath is picked up.
.validate: &validate
stage: build
script:
- 'mvn $MAVEN_CLI_OPTS test-compile'
# For merge requests do not `deploy` but only run `verify`.
# See https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
.verify: &verify
stage: test
script:
- 'mvn $MAVEN_CLI_OPTS verify site site:stage'
except:
- master
# Validate merge requests using JDK7
validate:jdk7:
<<: *validate
image: maven:3.3.9-jdk-7
# Validate merge requests using JDK8
validate:jdk8:
<<: *validate
image: maven:3.3.9-jdk-8
# Verify merge requests using JDK7
verify:jdk7:
<<: *verify
image: maven:3.3.9-jdk-7
# Verify merge requests using JDK8
verify:jdk8:
<<: *verify
image: maven:3.3.9-jdk-8
# For `master` branch run `mvn deploy` automatically.
# Here you need to decide whether you want to use JDK7 or 8.
# To get this working you need to define a volume while configuring your gitlab-ci-multi-runner.
# Mount your `settings.xml` as `/root/.m2/settings.xml` which holds your secrets.
# See https://maven.apache.org/settings.html
deploy:jdk8:
# Use stage test here, so the pages job may later pickup the created site.
stage: test
script:
- 'mvn $MAVEN_CLI_OPTS deploy site site:stage'
only:
- master
# Archive up the built documentation site.
artifacts:
paths:
- target/staging
image: maven:3.3.9-jdk-8
pages:
image: busybox:latest
stage: deploy
script:
# Because Maven appends the artifactId automatically to the staging path if you did define a parent pom,
# you might need to use `mv target/staging/YOUR_ARTIFACT_ID public` instead.
- mv target/staging public
dependencies:
- deploy:jdk8
artifacts:
paths:
- public
only:
- master
我们也可以根据需求自行定义。
在我目前的项目中，真正拉起CI可能需要2、3个repo同时协作——因为每个repo基于父级repo开发。父级repo是开源版的ZStack，而二级repo是基于我自己定制的Iaas增强模块，三级repo可能是业务逻辑模块。因此得写点脚本来组织这些东西。然后在这个过程中，我也发现了一个坑——每到一个新stage都会重新切换到当前目录。
Install runner
参考官方文章走下来是没什么问题的。
当你注册Runner的时候，会有一个类似的交互界面，如下：
gitlab-ci-multi-runner register
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://mygitlab.com/ci
Please enter the gitlab-ci token for this runner
xxx-xxx-xxx
Please enter the gitlab-ci description for this runner
my-runner
INFO[0034] fcf5c619 Registering runner... succeeded
Please enter the executor: shell, docker, docker-ssh, ssh?
docker
Please enter the Docker image (eg. ruby:2.1):
node:4.5.0
INFO[0037] Runner registered successfully. Feel free to start it, but if it's
running already the config should be automatically reloaded!
这里的gitlab-ci token需要管理员权限才可以获取。
its work
之后便可以在CI界面中看到当前Pipeline的状态了，可以基于Branch来跑，前提是你按照如上配置了。
图中这个状态明显是失败了，失败于第二个stage。当然，你可以直接点击最右边开始retry。
同样的，Pipeline也可以在merge request中使用。
我们可以选择在Pipeline跑好后merge或者直接merge。
小结
简单的和大家一起了解了一下GitLab CI，以及如何使用和踩的小坑还有跑起来的样子。
网友评论