GitLab CI持续集成 - .gitlab-ci.yml

在以前的文章中介绍了:

GitLab CI持续集成 - GitLab Runner 安装与注册

GitLab CI持续集成-GitLab Runner

配置好环境下一步能够正式开始使用GitLab CI进行项目集成，这里以Java项目为例，使用Gradle作为项目自动构建工具，使用Gradle工具作代码质量检查，详情参见使用Gradle作Java代码质量检查。

.gitlab-ci.yml

Gitlab CI使用YAML文件(.gitlab-ci.yml)来管理项目配置。该文件存放于项目仓库的根目录，它定义该项目如何构建。

YAML是一个可读性高，用来表达数据序列的格式。YAML参考了其余多种语言，包括:C语言、Python、Perl，并从XML，电子邮件的数据格式中得到灵感。
YAML是"YAML Ain't a Markup Language"(YAML不是一种标记语言)的递归缩写。在开发的这种语言时，YAML的意思实际上是:"Yet Another Markup Language"(还是一种标记语言)，但为了强调这种语言以数据做为中心，而不是以标记语言为重点，而用反向缩略语重命名。 --- 维基百科

.gitlab-ci.yml文件定义了一系列带有约束说明的任务，这些任务都是以任务名开始要包含script部分，一个.gitlab-ci.yml的例子:

stages:
  - unit-test


UnitTest:
  stage: unit-test
  tags:
    - spring-sample
  script:
    - gradle test
    - gradle jacocoTestReport
    - gradle sonarqube
  when: always

下面详细解释下脚本中字段的含义

构建脚本解析

stages定义能够被调用的阶段，默认定义为build,test和deploy，执行顺序：

1. 相同stage的job能够平行执行。
2. 下一个stage的job会在前一个stage的job成功后开发执行

这里定义了一个stage：unit-test。
下面的UnitTest是定义的一个任务，这个任务在stage为unit-test时执行。
tags表示他须要执行的gitlab-runner，这里在一个tag为spring-sample的tag中执行。
script表明须要执行的脚本，该例子中执行的脚本包括三步：

1. 运行gradle测试
2. 进行单元测试覆盖状况检查
3. 运行sonarqube进行代码质量检查

when定义什么时候执行任务，能够是on_success，on_failure，always(每次代码更新都触发)或者manual(手动触发)。

另外，比较经常使用的字段还有:
before_script 用来定义全部job以前运行的命令，包括部署任务等,能够是一个数组或者是多行字符串
after_script 用来定义全部job以后运行的命令。它必须是一个数组或者多行字符串
例如：

job:
  before_script:
  - execute this instead of global before script
  script:
  - my command
  after_script:
  - execute this after my script

cache用来指定须要缓存的文件或目录，例如：

job1:
  script: test
  cache:
    paths:
    - binaries/
    - .config

更多字段能够参考官方文档。

运行GitLab CI

配置完成以后，当把代码push到版本库中时就能够在CI/CD中看到相关的jobs:

进入详情能够看到详细的项目构建信息，能够根据产生的日志跟踪错误缘由，这里出错的缘由是在gitlab-ruuner中没有安装gradle的环境，安装完gradle环境以后构建任务运行经过。Ubuntu 安装 Java JDK & Gradle

引用

YAML: https://zh.wikipedia.org/wiki...
GitLab CI/CD Pipeline Configuration Reference ：https://docs.gitlab.com/ee/ci...
经过 .gitlab-ci.yml配置任务：https://github.com/Fennay/git...