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

42次阅读

共计 1708 个字符,预计需要花费 5 分钟才能阅读完成。

在之前的文章中介绍了:
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,执行顺序:

相同 stage 的 job 可以平行执行。
下一个 stage 的 job 会在前一个 stage 的 job 成功后开发执行

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

运行 gradle 测试
进行单元测试覆盖情况检查
运行 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…

正文完
 0