整理一下 .gitlab-ci.yml 文件的配置
job
job 是一组具有约束的作业,可以指定无限数量的 job 。
job 被定义为具有任意名称的顶级元素,并且始终必须至少包含该 script 子句。
job 必须具有唯一的名称,下面是一些保留的关键字不可以作为 job 的名称。
image
services
stages
types
before_script
after_script
variables
cache
作业由定义作业行为的参数列表定义
关键词 | 是否必须 | 描述 |
---|---|---|
script | yes | 定义由Runner执行的shell脚本 |
extends | no | 定义此 job 将继承的配置条目 |
image | no | 使用 Docker 镜像 |
services | no | 使用 Docker 服务 |
stage | no | 定义 job 阶段(默认:test) |
type | no | stage 的别名 |
variables | no | 在 job 级别定义 job 变量 |
only | no | 定义为其创建 job 的 git refs 列表 |
except | no | 定义未创建 job 的 git refs 列表 |
tags | no | 定义用于选择Runner的标记列表 |
allow_failure | no | 允许 job 失败,失败的 job 不会贡献 commit status |
when | no | 定义何时运行 job 。可以是 on_success,on_failure,always 或 manual |
dependencies | no | 定义 job 所依赖的其他 job ,以便您可以在它们之间传递 artifacts |
extends | no | job artifacts 依赖列表 |
cache | no | 定义后续运行之间应缓存的文件列表 |
before_script | no | 覆盖 job 前执行的一组命令 |
after_script | no | 覆盖 job 后执行的一组命令 |
environment | no | 定义此 job 完成部署的环境名称 |
coverage | no | 定义给定 job 的代码覆盖率设置 |
retry | no | 定义在发生故障时可以自动重试 job 的次数 |
- extends
在 GitLab 11.3 中引入
extends 定义要使用的 job extends 将继承的条目名称。
extends 替代使用更灵活和可读的 YAML 锚点。
例如下面两段代码
.tests:
only:
refs:
- branches
rspec:
extends: .tests
script: rake rspec
stage: test
only:
variables:
- $RSPEC
在上面的示例中,rspec作业将从 .tests 模板继承。GitLab 将执行反向深度合并,这意味着它将以递归方式合并 rspec 内容
.tests,并且将导致以下配置 rspec 作业:
rspec:
script: rake rspec
stage: test
only:
refs:
- branches
variables:
- $RSPEC
.tests在此示例中是隐藏密钥,但也可以从常规作业继承。
隐藏密钥:
在 GitLab 8.6 和 GitLab Runner v1.1.1 中引入。
如果要暂时“禁用”作业,而不是注释掉定义作业的所有行,可以像下面这样
你可以用点(.)开始它的名字,它不会被 GitLab CI 处理。在以下示例中,.hidden_job 将被忽略:
// 注释
#hidden_job:
# script:
# - run test
// 隐藏密钥
.hidden_job:
script:
- run test
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
extends 跨配置文件结合使用 include 。
YAML:
YAML有一个名为“anchors”的便捷功能,可让您轻松复制文档中的内容。Anchor可用于复制/继承属性,是与隐藏键 一起使
用以提供作业模板的完美示例。
以下示例使用锚点和映射合并。它将创建两个作业, test1并且test2将继承参数.job_template,每个作业都有自己定义的自
script定义:
.job_template: &job_definition # Hidden key that defines an anchor named 'job_definition'
image: ruby:2.1
services:
- postgres
- redis
test1:
<<: *job_definition # Merge the contents of the 'job_definition' alias
script:
- test1 project
test2:
<<: *job_definition # Merge the contents of the 'job_definition' alias
script:
- test2 project
& 设置 anchor(job_definition)的名称,<< 意味着“将给定的哈希合并到当前的哈希”,并 * 包括命名锚( job_definition )。扩展版本如下所示:
.job_template:
image: ruby:2.1
services:
- postgres
- redis
test1:
image: ruby:2.1
services:
- postgres
- redis
script:
- test1 project
test2:
image: ruby:2.1
services:
- postgres
- redis
script:
- test2 project
让我们看另一个例子。这次我们将使用锚来定义两组服务。这将创建两个作业,test:postgres 并且 test:mysql,将共享 script 中定义的指令 .job_template,并 services 指令定义 .postgres_services 和 .mysql_services 分别为:
.job_template: &job_definition
script:
- test project
.postgres_services:
services: &postgres_definition
- postgres
- ruby
.mysql_services:
services: &mysql_definition
- mysql
- ruby
test:postgres:
<<: *job_definition
services: *postgres_definition
test:mysql:
<<: *job_definition
services: *mysql_definition
扩展版本如下所示:
.job_template:
script:
- test project
.postgres_services:
services:
- postgres
- ruby
.mysql_services:
services:
- mysql
- ruby
test:postgres:
script:
- test project
services:
- postgres
- ruby
test:mysql:
script:
- test project
services:
- mysql
- ruby
pages
pages 是一项特殊工作,用于将静态内容上传到 GitLab,可用于为您的网站提供服务。它有一个特殊的语法,因此必须满足以下两个要求:
- 任何静态内容都必须放在 public/ 目录下
- artifactspublic/ 必须定义目录的路径
下面的示例只是将项目根目录中的所有文件移动到 public/ 目录中。该 .public 解决方法是这样 cp 不也复制 public/ 到自身无限循环:
pages:
stage: deploy
script:
- mkdir .public
- cp -r * .public
- mv .public public
artifacts:
paths:
- public
only:
- master