Gitlab CI yaml配置文件详解
上一篇 / 下一篇 2020-07-04 11:58:03 / 个人分类:持续集成
文章来源
- 文章来源:【转载】
通过 .gitlab-ci.yml配置任务
git仓库:https://github.com/Fennay/git...
此文档用于描述.gitlab-ci.yml语法,.gitlab-ci.yml文件被用来管理项目的runner 任务。
如果想要快速的了解GitLab CI ,可查看快速引导。
.gitlab-ci.yml
从7.12版本开始,GitLab CI使用YAML文件(.gitlab-ci.yml)来管理项目配置。该文件存放于项目仓库的根目录,它定义该项目如何构建。51Testing软件测试网|4vW&\*L {0L
开始构建之前YAML文件定义了一系列带有约束说明的任务。这些任务都是以任务名开始并且至少要包含script
部分:
job1:
script. "execute-script-for-job1"
job2:
script. "execute-script-for-job2"
上面这个例子就是一个最简单且带有两个独立任务的CI配置,每个任务分别执行不同的命令。
C q0I,{rGt,W|n%N"[0script
可以直接执行系统命令(例如:./configure;make;make install)或者是直接执行脚本(test.sh)。51Testing软件测试网/R0S(Q:y*H
任务是由Runners接管并且由服务器中runner执行。更重要的是,每一个任务的执行过程都是独立运行的。51Testing软件测试网|1M3N2d,Y4ae?Vr|
用下面这个例子来说明YAML语法还有更多复杂的任务:51Testing软件测试网}%\7~k H
image: ruby:2.1
services:
- postgres
before_script. - bundle install
after_script. - rm secrets
stages:
- build
- test
- deploy
job1:
stage: build
script. - execute-script-for-job1
only:
- master
tags:
- docker
下面列出保留字段,这些保留字段不能被定义为job
名称:
关键字 | 是否必须 | 描述 |
---|---|---|
image | 否 | 用于docker镜像,查看docker文档 |
services | 否 | 用于docker服务,查看docker文档 |
stages | 否 | 定义构建阶段 |
types | 否 | stages 的别名(已废除) |
before_script | 否 | 定义在每个job之前运行的命令 |
after_script | 否 | 定义在每个job之后运行的命令 |
variable | 否 | 定义构建变量 |
cache | 否 | 定义一组文件列表,可在后续运行中使用 |
image和services
这两个关键字允许使用一个自定义的Docker镜像和一系列的服务,并且可以用于整个job周期。详细配置文档请查看a separate document。51Testing软件测试网_JH%}1cxdq@
before_script
before_script
用来定义所有job之前运行的命令,包括deploy(部署) jobs,但是在修复artifacts之后。它可以是一个数组或者是多行字符串。51Testing软件测试网9c'oNW]j
after_script
GitLab 8.7 开始引入,并且要求Gitlab Runner v1.2
after_script
用来定义所有job之后运行的命令。它必须是一个数组或者是多行字符串
stages
stages
用来定义可以被job调用的stages。stages的规范允许有灵活的多级pipelines。
stages中的元素顺序决定了对应job的执行顺序:51Testing软件测试网+b QU-o ML#m\
1. 相同stage的job可以平行执行。
2. 下一个stage的job会在前一个stage的job成功后开始执行。
接下仔细看看这个例子,它包含了3个stage:
!H ew7N2I*h/W0stages:
- build
- test
- deploy
- 首先,所有
build
的jobs都是并行执行的。 - 所有
build
的jobs执行成功后,test
的jobs才会开始并行执行。 - 所有
test
的jobs执行成功,deploy
的jobs才会开始并行执行。 - 所有的
deploy
的jobs执行成功,commit才会标记为success
- 任何一个前置的jobs失败了,commit会标记为
failed
并且下一个stages的jobs都不会执行。
这有两个特殊的例子值得一提:51Testing软件测试网'PiDj!gG#f!T
- 如果
.gitlab-ci.yml
中没有定义stages
,那么job's stages 会默认定义为build
,test
和deploy
。 - 如果一个job没有指定
stage
,那么这个任务会分配到test
stage。
types
已废除,将会在10.0中移除。用stages替代。
与stages同义51Testing软件测试网Xv Hp7O
variables
GitLab Runner V0.5.0. 开始引入
GItLab CI 允许在.gitlab-ci.yml
文件中添加变量,并在job环境中起作用。因为这些配置是存储在git仓库中,所以最好是存储项目的非敏感配置,例如:
variables:
DATABASE_URL:"postgres://postgres@postgres/my_database"
这些变量可以被后续的命令和脚本使用。服务容器也可以使用YAML中定义的变量,因此我们可以很好的调控服务容器。变量也可以定义成job level。51Testing软件测试网#Byo'S!Ypj)X
除了用户自定义的变量外,Runner也可以定义它自己的变量。CI_COMMIT_REG_NAME
就是一个很好的例子,它的值表示用于构建项目的分支或tag名称。除了在.gitlab-ci.yml
中设置变量外,还有可以通过GitLab的界面上设置私有变量。51Testing软件测试网J)_b]5IN
cache
Gitlab Runner v0.7.0 开始引入。
cache
用来指定需要在job之间缓存的文件或目录。只能使用该项目工作空间内的路径。
从GitLab 9.0开始,pipelines和job就默认开启了缓存
8z3BRMg9P6b-l&_@u0如果cache
定义在jobs的作用域之外,那么它就是全局缓存,所有jobs都可以使用该缓存。
缓存binaries
和.config
中的所有文件:51Testing软件测试网
v^N9T\0]l5m%K
rspec:
script. test
cache:
paths:
- binaries/
- .config
缓存git中没有被跟踪的文件:51Testing软件测试网8qW7mf"@qJ-M)DkB
rspec:
script. test
cache:
untracked: true
缓存binaries
下没有被git跟踪的文件:
rspec:
script. test
cache:
untracked: true
paths:
- binaries/
job中优先级高于全局的。下面这个rspec
job中将只会缓存binaries/
下的文件:
cache:
paths:
- my/files
rspec:
script. test
cache:
key: rspec
paths:
- binaries/
注意,缓存是在jobs之前进行共享的。如果你不同的jobs缓存不同的文件路径,必须设置不同的cache:key,否则缓存内容将被重写。
)q9az8}8G:j` ^0缓存只是尽力而为之,所以别期望缓存会一直存在。查看更多详细内容,请查阅GitLab Runner。
.b'^T1f5~8],A0缓存key
GitLab Runner v1.0.0 开始引入。
key
指令允许我们定义缓存的作用域(亲和性),可以是所有jobs的单个缓存,也可以是每个job,也可以是每个分支或者是任何你认为合适的地方。51Testing软件测试网:?]]o$O
它也可以让你很好的调整缓存,允许你设置不同jobs的缓存,甚至是不同分支的缓存。51Testing软件测试网 oh,l)V Q*|!@SVu na
cache:key
可以使用任何的预定义变量。
默认key是默认设置的这个项目缓存,因此默认情况下,每个pipelines和jobs中可以共享一切,从GitLab 9.0开始。
4?_I!{7@)m8S0配置示例
M'?B-\3OAe0缓存每个job:51Testing软件测试网:P0UC9N9KL
cache:
key: "$CI_JOB_NAME"
untracked: true
缓存每个分支:
rN~/RC(iA0cache:
key: "$CI_COMMIT_REF_NAME"
untracked: true
缓存每个job且每个分支:51Testing软件测试网;Em?+ZFC(p R1|
cache:
key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME"
untracked: true
缓存每个分支且每个stage:51Testing软件测试网?$b7R)s N5IT
cache:
key: "$CI_JOB_STAGE/$CI_COMMIT_REF_NAME"
untracked: true
如果使用的Windows Batch(windows批处理)来跑脚本需要用%
替代$
:51Testing软件测试网cY|m
f7[NU2d
cache:
key: "%CI_JOB_STAGE%/%CI_COMMIT_REF_NAME%"
untracked: true
Jobs
.gitlab-ci.yml
允许指定无限量jobs。每个jobs必须有一个唯一的名字,而且不能是上面提到的关键字。job由一列参数来定义jobs的行为。
job_name:
script. - rake spec
- coverage
stage: test
only:
- master
except:
- develop
tags:
- ruby
- postgres
allow_failure: true
Keyword | Required | Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
script | yes | Runner执行的命令或脚本 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
image | no | 所使用的docker镜像,查阅使用docker镜像 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
services | no | 所使用的docker服务,查阅使用docker镜像 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
stage | no | 定义job stage(默认:test ) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
type | no | stage 的别名(已弃用) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
variables | no | 定义job级别的变量 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
only | no | 定义一列git分支,并为其创建job | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
except | no | 定义一列git分支,不创建job | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
tags | no | 定义一列tags,用来指定选择哪个Runner(同时Runner也要设置tags) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
allow_failure | no | 允许job失败。失败的job不影响commit状态 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
when | no | 定义何时开始job。可以是on_success ,on_failure ,always 或者manual | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
dependencies |
TAG: gitlab 生活在互联网领域,从事WEB测试工作. 我的栏目标题搜索日历
我的存档数据统计
清空Cookie - 联系我们 - 51Testing软件测试网 - 交流论坛 - 空间列表 - 站点存档 - 升级自己的空间
Powered by 51Testing
© 2003-2021
|