在.gitlab-ci.yml中配置你的工作流
这篇文章描述了.gitlab-ci.yml
的用法,.gitlab-ci.yml文件被Gitlab Runner用来管理你的jobs。
从7.12版本开始,Gitlab CI 用YAML文件(.gitlab-ci.yml
)来配置项目。它被放置在你仓库的根目录并且应该包含YAML如何构建你项目的定义。如果你先要Gitlab CI的快速介绍,可以看下我们的快速快开始指导
注意:如果你有镜像仓库需要Gitlab去拉取,你可能需要开启pipeline triggering,在你的项目中设置Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates.
Jobs
YAML文件定义了一些job,这些job限制了他们应该被运行的时间。你可以在文件的顶层中指定无限的job,他们可以随意命名,并且至少包含一个script条目
job1:
script: "execute-script-for-job1"
job2:
script: "execute-script-for-job2"
上面的例子是CI/CD配置可以的最简单的配置,有两个分离的job,每一个job执行不同的命令,当然命令可以直接在仓库中执行代码(./configure; make;make install
)或者运行脚本(test.sh
).
Job被Runner挑选出来,并且在Runner环境中执行,最重要的是每个Job相对与其他Job是独立运行的。
每个Job必须包含唯一的名字,但是这里有一些保留的关键字不能被用作Job的名称:
- image
- services
- stages
- types
- before_script
- after_script
- variables
- cache
一个job通过以下一些定义job行为的参数定义而成。
关键字 | 是否必须 | 描述 |
---|---|---|
script | yes | 定义Runner执行的shell脚本 |
extends | no | 定义当前job继承配置的入口 |
image | no | 定义脚本镜像,涵盖在Docker镜像使用 |
services | no | 使用docker services,涵盖在使用Docker镜像 |
stage | no | 定义job的stage(默认:test) |
type | no | stage的别名 |
variables | no | 在job层定义变量 |
only | no | 定义创建job的git refs的列表 |
except | no | 定义不创建job的git refs的列表 |
tags | no | 定义用来选择Runner的tag列表 |
allow_failure | no | 允许job失败,失败的job无助于commit的状态 |
when | no | 定义何时运行job可以是on_success ,on_failure ,always 或者manual
|
dependencies | no | 定义另外的job作为当前job的依赖,这样你就可以在他们之间传递工件 |
artifacts | no | 定义job工件列表 |
cache | no | 定义应该被缓存起来的东西,以便在下次run的时候使用 |
before_script | no | 定义在job之前执行的命令列表 |
after_script | no | 定义在job之后执行的命令列表 |
environment | no | 定义由该job完成发布的环境的名称 |
converage | no | 定义该job代码覆盖率的设置 |
retry | no | 定义在失败的情况下可以自动重试多少次 |
parallel | no | 定义多少job实例可以同时运行 |
extends
在Gitlab11.3中引入
extends定义继承的job的名称。他是使用YAML anchors的替代方案,它更加灵活,并且可读性更强:
.tests:
script: rake test
stage: test
only:
refs:
- branches
rspec:
extends: .tests
script: rake rspec
only:
variables:
- $RSPEC
在上面的例子中rspc
这个job继承了.tests
这个模版job。GitLab将会根据keys执行反向深度合并。Gitlab将会:
- 递归合并rspec的内容到.tests
- 不合并键的值
rspec job的结果如下:
rspec:
script: rake rspec
stage: test
only:
refs:
- branches
variables:
- $RSPEC
注意:
script: rake test
已经被script:rake rspec
合并了。
如果你想要包含rake test
,看看before_script-and-after_script.
.tests
在这个例子中是一个隐藏的key,但是它也可以继承自正常的job.
extends
支持多层继承,但是不建议超过三层的继承。最多支持的嵌套层级是10层。下面的例子有两个层级的嵌套。
.tests:
only:
- pushes
.rspec:
extends: .tests
script: rake rspec
rspec 1:
variables:
RSPEC_SUITE: '1'
extends: .rspec
rspec 2:
variables:
RSPEC_SUITE: '2'
extends: .rspec
spinach:
extends: .tests
script: rake spinach
跨文件的extend
结合include一起使用
pages
pages
是一个特殊的job,它被用来上传一些服务网站的静态资源到GitLab.它有特殊的语法,必须满足以下两点:
- 所有的静态资源必须在
public/
目录下 -
artifacts
的path地址必须被定义成public/
下面的例子简单的将所有文件从根目录下移动到public/
文件下。使用.public
所以cp
命令不会无限循环的拷贝public/
到它自己目录下
pages:
stage: deploy
script:
- mkdir .public
- cp -r * .public
- mv .public public
artifacts:
paths:
- public
only:
- master
详情阅读GitLab Pages user documentation.
image 和 services
该字段允许指定在job工作时间可用的自定义的Docker镜像和services列表。此功能的介绍在单独的文章中介绍。
before_script 和 after_script
注意:在GitLab8.7中引入,并且需要Runner V1.2
before_script
被用来定义一些需要在所有job之前执行的命令,包括发布job,但是在artifacts恢复之后。它可以是数组或者多行字符串。after_script
被用来定义一些在所有job运行之后执行的命令,包括失败的那些。它必须是数组或者多行字符串。
before_script
和主 script
在一个上下文/容器中运行。after_script
是分离运行的,所以根据执行程序的不同,在工作树之外的改变可能不可见。比如:在before_script
安装软件。
它可以覆盖掉你在全局设置的before_script
和after_script
:
before_script:
- global before script
job:
before_script:
- execute this instead of global before script
script:
- my commandling
after_script:
- execute this after my script
stages
stages
被用来在全局定义可用的job.
指定的stages允许拥有灵活的多个stage的pipelines。节点定义的顺序就是job执行的顺序:
- 在同一个stage中指定的job将会同时运行。
- 下一个stage将会在上一个stage完全成功后运行。
让我们思考如下示例,它定义了三个stage:
stages:
- build
- test
- deploy
- 首先,在
build
中的所有job将会同时运行。 - 如果
build
中的所有job运行成功,则test
中的所有job将会同时运行 - 如果
build
中的所有job运行成功,则deploy
中的job将会同时运行。 - 如果
deploy
中的所有job运行成功,则commit将会标记为passed
. - 如果任何一个之前的job执行失败,则commit将会被标记为失败,并且之后stage中的所有job都不会执行。
这里还有两个值得一提的边缘例子:
- 如果
.gitlab-ci.yml
中没有定义stages
,这样的话默认情况下build
,test
,deploy
可以在job的stage中被使用。 - 如果job没有指定
stage
,那么job将被分配test
stage.
stage
stage
定义每一个job依赖的在全局stages
中定义的stage
.它允许一组job定义在不同的stage中,同一个stage
中的job同时执行。比如:
stages:
- build
- test
- deploy
job 1:
stage: build
script: make build dependencies
job 2:
stage: build
script: make build artifacts
job 3:
stage: test
script: make test
job 4:
stage: deploy
script: make deploy
types
Deprecated:
types
已经被弃用了,并且可能会在未来的某个版本中移除,用stages
代替
script
script
是job中唯一一个必须要有的。这是一段Runner执行的shell脚本。比如:
job:
script: "bundle exec rspec"
此参数还可以用数组包含一系列命令脚本:
job:
script:
- uname -a
- bundle exec rspec
有些时候,script
脚本可能需要用单引号或者双引号来包裹。比如:命令包含冒号(:
)需要用引号包裹这样的化YAML解析器在解析的时候知道这是一个字符串而不是"key:value"这样的键值对。使用这些特殊字符串的时候要小心: :, {, }, [, ], , &, *, #, ?, |, -, <, >, =, !, %, @, , `.
only 和 except (simplified)
only
和except
是用来设置job策略限时何时创建job的两个参数:
-
only
定义job运行的分支的名字,或者定义为tags(译者注:打tag的时候会运行) -
except
定义不运行job的分支名称或者tags
这里有一些规则适用于工作策略的使用:
-
only
和except
都包括。如果only
和except
在一个job中都被定义,ref将会被only
和except
过滤。 -
only
和except
允许使用常规表达式(使用Ruby regexp syntax). -
only
和except
允许指定仓库地址去过滤fork的仓库。
另外,only
和except
允许使用特殊的关键字:
Value | Description |
---|---|
branched | 当git refrence在pipeline中是一个分支的时候 |
tag | git refrence在pipeline中是一个tag的时候 |
api | 当pipeline被第二个pipeline触发的api(不是触发API) |
external | 当使用的CI服务不是gitLab |
pipelines | 对于多项目触发,创建使用有CI_JOB_TOKEN 的API |
pushes | 当用户使用git push 的时候Pipeline触发 |
schedules | 看( scheduled pipelines)[https://docs.gitlab.com/ee/user/project/pipelines/schedules.html] |
triggers: 使用trigger token创建pipelines
web|使用Gitlab UI上的Run pipeline创建pipeline(在你项目的Pipelines中)
merge_requests|当merge request被创建或者更新的时候(看pipelines for merge requests)
在下面的例子中,job只会在以issue-
开头的refs中运行,然而所有的分支将会被跳过
job:
# use regexp
only:
- /^issue-.*$/
# use special keyword
except:
- branches
在下面的例子中,job只会在被打过tag或者明确指定通过触发API请求构建或者Pipeline Schedule被的refs中被引用:
job:
# use special keywords
only:
- tags
- triggers
- schedules
仓库地址能够被用来指定只有父仓库能够执行job而fork的不行:
job:
only:
- branches@gitlab-org/gitlab-ce
except:
- master@gitlab-org/gitlab-ce
上面的例子将会在gitlab-org/gitlab-ce
的所有分支上运行job,而排除master分支
如果job既没有only
也没有except
规则,默认设置为:only: ['branches', 'tags']
比如:
job:
script: echo 'test'
被翻译成:
job:
script: echo 'test'
only: ['branches', 'tags']
only 和 except (complex)
refs
和kubernetes
策略在Gitlab10.0中被引入
variables
策略在10.7中被引用
changes
策略在11.4中被引入
Warning:这是一个alpha的功能,它在任何时候都有可能在没有提前通知的情况下改变。
从Gitlab10.0开始only/except job策略可以被定义的更加细致。
Gitlab现在支持simple和complex两种策略,所以可以使用数组和哈希配置方案。
四个键现在是有效的refs
,kubernetes
,variables
,changes
.
refs 和 kubernetes
Refs策略和简单模式下的only/except配置一样,而kubernetes策略和只接受active
关键字。
only:variables
variables
关键字被用来定义变量表达式。换句话说可以被用来与定义变量/项目/组或者环境范围变量去定义一个表达式Gitlab将会去评估,决定job是否需要被创建。
看下面的例子。job只会在pipeline有scheduled或者运行的master
分支,并且kubernetes在项目中是active的时候会被创建。
job:
only:
refs:
- master
- schedules
kubernetes: active
变量表达式的例子:
deploy:
script: cap staging deploy
only:
refs:
- branches
variables:
- $RELEASE == "staging"
- $STAGING
执行job依赖commit message的用例(在11.0中增加):
end-to-end:
script: rake test:end-to-end
except:
variables:
- $CI_COMMIT_MESSAGE =~ /skip-end-to-end-tests/
学习更多的变量表达式在另一个单独的页面
only:changes
在only
或者except
关键字使得根据git push的文件是否修改来判断job是否应该被创建成为可能。
比如:
docker build:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
only:
changes:
- Dockerfile
- docker/scripts/*
- dockerfiles/**/*
- more_scripts/*.{rb,py,sh}
在上面的例子中,如果你push 多个commit到GitLab现有的分支上,只要提供的commit中有一个包含以下改变,Gitlab将会创建并出发docker build
:
-
Dockerfile
文件 - 任何在
docker/scripts/
文件夹下的文件 - 任何在
dockerfiles
文件夹下面的文件或者子文件夹 - 任何在
more_scripts
文件夹下以rb, py, sh
为扩展名的文件
Warning:在新的分支或者tags上面使用这个功能的时候,这里有一些注意事项,看一下面一个章节。
在新的分支或者tags上面使用changes
如果你push新的分支或者tag到Gitlab上面,这个策略将会总是被评估为true,并且Gitlab将会创建job.到目前为止,这个功能还没有于merge requests联系在一起,因为GitLab创建pipeline是在用户创建merge request之前,在这个时候我们无法知道目标分支是哪个。
没有目标分支,不可能知道共同的祖先是谁,因此在这种情况下我们总是创建job.这个功能最好在稳定的分支上工作,因为在这中情况下Gitlab使用分支中上次commit的结果于这次push的SHA做比较。
tags
tags
被用来从Runner列表中选择允许在这个项目中运行的Runner.
在注册Runner期间你可以指定Runner的tag,比如ruby, postgres, development
.
tags允许你在job中运行指定的job:
job:
tags:
- ruby
- postgres
在上面的例子中,我们确保job构建的Runner定义了ruby
和postgres
的标签。
Tags也是一个在不同的平台上运行不同job的好方法,比如给OSX Runner的tag赋值osx
给Window Runner赋值windows
tag,下面的job运行在各自的平台:
windows job:
stage:
- build
tags:
- windows
script:
- echo Hello, %USERNAME%!
osx job:
stage:
- build
tags:
- osx
script:
- echo "Hello, $USER!"
网友评论