嘗試使用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