尝试使用GitLab-CI

本文首发于 泊浮目的简书: https://www.jianshu.com/u/204...

背景

我常常写测试——这算是我对软件工程的一点执念。前阵子折腾了基于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（阶段）。好比编译->测试->部署等。

尝试工做

首先来到项目的主页，咱们能够看到设置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可能须要二、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，以及如何使用和踩的小坑还有跑起来的样子。

参考资料：

• GitLab Continuous Integration (GitLab CI/CD)
• GitLab-CI 从安装到差点放弃
• Gitlab 9中的CI与Runner遇到maven工程遇到的问题
• GitLab-CI与GitLab-Runner