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软件测试网am@QM1F
开始构建之前YAML文件定义了一系列带有约束说明的任务。这些任务都是以任务名开始并且至少要包含script
部分:
job1:
script. "execute-script-for-job1"
job2:
script. "execute-script-for-job2"
上面这个例子就是一个最简单且带有两个独立任务的CI配置,每个任务分别执行不同的命令。51Testing软件测试网g4j[#Ld/d2@x%~C
script
可以直接执行系统命令(例如:./configure;make;make install)或者是直接执行脚本(test.sh)。
任务是由Runners接管并且由服务器中runner执行。更重要的是,每一个任务的执行过程都是独立运行的。
-lIz&Lq7V*Ag_0用下面这个例子来说明YAML语法还有更多复杂的任务:
,M^ g9g f"u0image: 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。
a Fi$H,b"H_4r0before_script
before_script
用来定义所有job之前运行的命令,包括deploy(部署) jobs,但是在修复artifacts之后。它可以是一个数组或者是多行字符串。51Testing软件测试网!v"Q4l#P/J?ut;n7F
after_script
GitLab 8.7 开始引入,并且要求Gitlab Runner v1.2
after_script
用来定义所有job之后运行的命令。它必须是一个数组或者是多行字符串
stages
stages
用来定义可以被job调用的stages。stages的规范允许有灵活的多级pipelines。51Testing软件测试网kk'^`$nrJ K
stages中的元素顺序决定了对应job的执行顺序:
YV)zq n;c8nS01. 相同stage的job可以平行执行。
2. 下一个stage的job会在前一个stage的job成功后开始执行。
接下仔细看看这个例子,它包含了3个stage:51Testing软件测试网2@c.Bt^WZ;b c
stages:
- build
- test
- deploy
- 首先,所有
build
的jobs都是并行执行的。 - 所有
build
的jobs执行成功后,test
的jobs才会开始并行执行。 - 所有
test
的jobs执行成功,deploy
的jobs才会开始并行执行。 - 所有的
deploy
的jobs执行成功,commit才会标记为success
- 任何一个前置的jobs失败了,commit会标记为
failed
并且下一个stages的jobs都不会执行。
这有两个特殊的例子值得一提:
{j~9C,f2A7Xl0- 如果
.gitlab-ci.yml
中没有定义stages
,那么job's stages 会默认定义为build
,test
和deploy
。 - 如果一个job没有指定
stage
,那么这个任务会分配到test
stage。
types
已废除,将会在10.0中移除。用stages替代。
与stages同义
$uh-qu#U|0variables
GitLab Runner V0.5.0. 开始引入
GItLab CI 允许在.gitlab-ci.yml
文件中添加变量,并在job环境中起作用。因为这些配置是存储在git仓库中,所以最好是存储项目的非敏感配置,例如:51Testing软件测试网(I!u
c#G [
variables:
DATABASE_URL:"postgres://postgres@postgres/my_database"
这些变量可以被后续的命令和脚本使用。服务容器也可以使用YAML中定义的变量,因此我们可以很好的调控服务容器。变量也可以定义成job level。51Testing软件测试网u-{,Im.c0CNNx`
除了用户自定义的变量外,Runner也可以定义它自己的变量。CI_COMMIT_REG_NAME
就是一个很好的例子,它的值表示用于构建项目的分支或tag名称。除了在.gitlab-ci.yml
中设置变量外,还有可以通过GitLab的界面上设置私有变量。
更多关于variables。51Testing软件测试网d.{z'N{3j!R4ShJ
cache
Gitlab Runner v0.7.0 开始引入。
cache
用来指定需要在job之间缓存的文件或目录。只能使用该项目工作空间内的路径。
从GitLab 9.0开始,pipelines和job就默认开启了缓存51Testing软件测试网!_J4G3O;^7yC
如果cache
定义在jobs的作用域之外,那么它就是全局缓存,所有jobs都可以使用该缓存。
缓存binaries
和.config
中的所有文件:
rspec:
script. test
cache:
paths:
- binaries/
- .config
缓存git中没有被跟踪的文件:51Testing软件测试网j+U3cFd/u+s
rspec:
script. test
cache:
untracked: true
缓存binaries
下没有被git跟踪的文件:51Testing软件测试网.Lvt^+N;PH*w
rspec:
script. test
cache:
untracked: true
paths:
- binaries/
job中优先级高于全局的。下面这个rspec
job中将只会缓存binaries/
下的文件:51Testing软件测试网X
Lc5f@V*c
cache:
paths:
- my/files
rspec:
script. test
cache:
key: rspec
paths:
- binaries/
注意,缓存是在jobs之前进行共享的。如果你不同的jobs缓存不同的文件路径,必须设置不同的cache:key,否则缓存内容将被重写。51Testing软件测试网%t7|u,^k;P
缓存只是尽力而为之,所以别期望缓存会一直存在。查看更多详细内容,请查阅GitLab Runner。51Testing软件测试网3]3F-E5D/e@TG
缓存key
GitLab Runner v1.0.0 开始引入。
key
指令允许我们定义缓存的作用域(亲和性),可以是所有jobs的单个缓存,也可以是每个job,也可以是每个分支或者是任何你认为合适的地方。
它也可以让你很好的调整缓存,允许你设置不同jobs的缓存,甚至是不同分支的缓存。
B%i%t+tBtH0cache:key
可以使用任何的预定义变量。
默认key是默认设置的这个项目缓存,因此默认情况下,每个pipelines和jobs中可以共享一切,从GitLab 9.0开始。
/pTp4}[+w7k0配置示例
Hc%IF*t|I0缓存每个job:
"W)t4F7U3tz]v"V Hf0cache:
key: "$CI_JOB_NAME"
untracked: true
缓存每个分支:
Ao*k6B?%Qh0cache:
key: "$CI_COMMIT_REF_NAME"
untracked: true
缓存每个job且每个分支:
:a@:QA.JSI.z~ g0cache:
key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME"
untracked: true
缓存每个分支且每个stage:
5Z*h*WK2g0cache:
key: "$CI_JOB_STAGE/$CI_COMMIT_REF_NAME"
untracked: true
如果使用的Windows Batch(windows批处理)来跑脚本需要用%
替代$
:
cache:
key: "%CI_JOB_STAGE%/%CI_COMMIT_REF_NAME%"
untracked: true
Jobs
.gitlab-ci.yml
允许指定无限量jobs。每个jobs必须有一个唯一的名字,而且不能是上面提到的关键字。job由一列参数来定义jobs的行为。51Testing软件测试网Xy"vI$|K
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
|