您的位置:首页 > 其它

Gitlab部署CI并使用.gitlab-ci.yml配置您的作业(中文翻译)

2017-04-12 13:23 776 查看
本文档描述了
.gitlab-ci.yml
GitLab
Runner用于管理项目作业的文件的用法。

如果您想快速介绍GitLab CI,请按照我们的 快速入门指南


.gitlab-ci.yml

从版本7.12,GitLab CI使用YAML 文件(
.gitlab-ci.yml
)进行项目配置。它放置在存储库的根目录中,并包含如何构建项目的定义。

YAML文件定义了一组具有约束的作业,说明何时应该运行它们。作业被定义为具有名称的顶级元素,并且必须至少包含
script
子句:
job1:
script: "execute-script-for-job1"

job2:
script: "execute-script-for-job2"


上述示例是具有两个单独作业的最简单的CI配置,其中每个作业执行不同的命令。

当然,命令可以直接(
./configure;make;make
install
)执行代码,也可以
test.sh
在存储库中运行一个script()。

工作由跑步者拾起并在跑步者的环境中执行。重要的是每项工作都是独立运作的。

YAML语法允许使用比上述示例中更复杂的作业规范:
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


有一些保留
keywords
是不能被用作作业名:
关键词需要描述
图片没有使用泊坞窗图像,满身是使用泊坞窗
服务没有使用泊坞窗服务,覆盖在使用泊坞窗
阶段没有定义构建阶段
类型没有别名
stages
(已弃用)
before_script没有定义在每个作业的脚本之前运行的命令
after_script没有定义在每个作业的脚本之后运行的命令
变量没有定义构建变量
缓存没有定义应该在后续运行之间缓存的文件列表


形象和服务

这允许指定一个自定义的Docker映像和一个可以用于作业时间的服务列表。此功能的配置在 单独的文档中介绍


before_script

before_script
用于定义在所有作业(包括部署作业)之前但在恢复工件之后应运行的命令。这可以是数组或多行字符串。


after_script

在GitLab 8.7中引入,需要Gitlab Runner v1.2

after_script
用于定义将在所有作业之后运行的命令。这必须是一个数组或多行字符串。


阶段

stages
用于定义作业可以使用的阶段。的说明书
stages
允许具有灵活的多阶段流水线。

元素
stages
的排序定义作业的执行顺序:

相同阶段的工作并行运行。
上一阶段的工作成功完成后,下一阶段的工作就会运行。

我们考虑下面的例子,它定义了3个阶段:
stages:
- build
- test
- deploy


首先,所有工作
build
都是并行执行的。
如果所有作业
build
成功,则
test
并行执行作业。
如果所有作业
test
成功,则
deploy
并行执行作业。
如果所有作业
deploy
成功,则提交将被标记为
success

如果以前任何一个作业失败,则提交将被标记为
failed
并且不执行进一步的作业。

还有两个值得一提的边缘案例:

如果没有
stages
被定义
.gitlab-ci.yml
,那么
build
test
deploy
允许被用作默认作业的阶段。
如果作业未指定
stage
作业,则将作业分配给
test
舞台。


类型

已弃用,并将在10.0中删除。使用阶段来代替。

别名为阶段


变量

在GitLab Runner v0.5.0中引入。

GitLab CI允许您添加
.gitlab-ci.yml
在作业环境中设置的变量。变量存储在Git存储库中,旨在存储非敏感项目配置,例如:
variables:
DATABASE_URL: "postgres://postgres@postgres/my_database"


这些变量可以在以后在所有执行的命令和脚本中使用。YAML定义的变量也设置为所有创建的服务容器,从而允许对其进行微调。也可以在作业层面定义变量 。

除了用户定义的变量,还有由Runner本身设置的变量。一个例子是
CI_COMMIT_REF_NAME
具有构建项目的分支或标签名称的值。除了可以设置的变量之外
.gitlab-ci.yml
,还有所谓的秘密变量,可以在GitLab的UI中设置。

了解有关变量的更多信息。


缓存

在GitLab Runner v0.7.0中引入。

cache
用于指定应该在作业之间缓存的文件和目录的列表。您只能使用项目工作区内的路径。

默认情况下,从GitLab 9.0开始,管道和作业之间启用缓存并共享

如果
cache
被定义在作业范围之外,则意味着它在全局设置,并且所有作业将使用该定义。

缓存的所有文件
binaries
.config

rspec:
script: test
cache:
paths:
- binaries/
- .config


缓存所有Git未跟踪的文件:
rspec:
script: test
cache:
untracked: true


缓存所有Git未跟踪的文件和文件
binaries

rspec:
script: test
cache:
untracked: truepaths:
- binaries/


本地定义的高速缓存覆盖全局定义的选项。以下
rspec
作业将仅缓存
binaries/

cache:
paths:
- my/files

rspec:
script: test
cache:
key: rspec
paths:
- binaries/


请注意,由于缓存在作业之间共享,如果您为不同作业使用不同的路径,那么还应该设置不同的缓存:key 否则缓存内容可以被覆盖。

缓存是尽力而为的,所以不要指望缓存将始终存在。有关实施细节,请查看GitLab Runner。


缓存:键

在GitLab Runner v1.0.0中引入。

key
指令允许您定义作业之间缓存的亲和度,允许为所有作业,每个作业缓存,每个分支缓存或任何其他您认为正确的方式拥有单个缓存。

这允许您微调缓存,允许您在不同的作业甚至不同的分支之间缓存数据。

cache:key
变量可以使用任何预定义的变量

项目默认的默认键是默认的,因此默认情况下,每个管道和作业之间共享一切,从GitLab 9.0开始。

示例配置

启用每个作业的缓存:
cache:
key: "$CI_JOB_NAME"
untracked: true


启用每分支缓存:
cache:
key: "$CI_COMMIT_REF_NAME"
untracked: true


启用每个作业和每个分支缓存:
cache:
key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME"
untracked: true


启用每个分支和每个阶段的缓存:
cache:
key: "$CI_JOB_STAGE/$CI_COMMIT_REF_NAME"
untracked: true


如果您使用Windows Batch来运行您的shell脚本,则需要替换
$
%

cache:
key: "%CI_JOB_STAGE%/%CI_COMMIT_REF_NAME%"
untracked: true


工作

.gitlab-ci.yml
允许您指定无限数量的作业。每个作业必须有一个唯一的名称,这不是上述关键字之一。作业由定义作业行为的参数列表定义。
job_name:
script:
- rake spec
- coverage
stage: test
only:
- master
except:
- develop
tags:
- ruby
- postgres
allow_failure: true

关键词需要描述
脚本定义由Runner执行的shell脚本
图片没有使用Docker图像,使用Docker图像
服务没有使用Docker Images使用码头服务
阶段没有定义一个工作阶段(默认:
test
类型没有别名为
stage
变量没有在作业级别定义作业变量
只要没有定义创建作业的git参考列表
没有定义未创建作业的git参考列表
标签没有定义用于选择Runner的标签列表
allow_failure没有允许作业失败。失败的作业无助于提交状态
什么时候没有定义何时运行作业。可以是
on_success
on_failure
always
或者
manual
依赖关系没有定义作业所依赖的其他作业,以便您可以在它们之间传递工件
文物没有定义作业文件列表
缓存没有定义应该在后续运行之间缓存的文件列表
before_script没有覆盖在作业之前执行的一组命令
after_script没有覆盖在作业后执行的一组命令
环境没有定义此作业完成部署的环境名称
覆盖面没有定义给定作业的代码覆盖率设置


脚本

script
是由Runner执行的shell脚本。例如:
job:
script: "bundle exec rspec"


此参数还可以包含使用数组的多个命令:
job:
script:
- uname -a
- bundle exec rspec


有时,
script
命令需要用单引号或双引号括起来。例如,包含冒号(
:
)的命令需要用引号括起来,以便YAML解析器知道将整个事物解释为字符串而不是“key:value”对。使用特殊字符时要小心:
:
{
}
[
]
,
&
*
#
?
|
-
<
>
=
!
%
@
`


阶段

stage
允许将作业分组到不同的阶段。
stage
执行相同的作业
parallel
。有关使用
stage
请查看 阶段的更多信息。


只有和除外

only
并且
except
是设置参考策略限制作业构建时的两个参数:

only
定义作业将要运行的分支和标签的名称。
except
定义作业不能运行的分支和标签的名称 。

有一些适用于参考资料政策使用的规则:

only
并且
except
是包容性的 如果同时
only
except
在作业规范中定义,裁判通过过滤
only
except

only
except
允许使用正则表达式。
only
except
允许使用特殊的关键字:
branches
tags
,和
triggers

only
except
允许指定一个存储库路径来过滤叉子的作业。

在下面的示例中,
job
将只针对以开头的参数运行
issue-
,而所有分支将被跳过。
job:
# use regexp
only:
- /^issue-.*$/
# use special keyword
except:
- branches


在这个例子中,
job
将仅对标记的引用运行,或者通过API触发器明确地请求构建。
job:
# use special keywords
only:
- tags
- triggers


存储库路径可用于仅为父存储库执行作业,而不是叉:
job:
only:
- branches@gitlab-org/gitlab-ce
except:
- master@gitlab-org/gitlab-ce


上述示例将运行
job
gitlab-org/gitlab-ce
除master之外的所有分支。


工作变量

可以使用
variables
作业级别的关键字来定义作业变量。它的工作原理与其全局级别的方法基本相同,但允许您定义作业特定的变量。

当在
variables
作业级使用关键字时,它将覆盖全局YAML作业变量和预定义作业变量。要关闭作业中的全局定义变量,请定义一个空数组:
job_name:
variables: []


作业变量优先级在变量文档中定义。


标签

tags
用于从允许运行此项目的所有跑步者列表中选择特定的赛跑者。

在一个亚军的注册,您可以指定亚军的标签,例如
ruby
postgres
development


tags
允许您运行具有分配给它们的指定标签的运行器的作业:
job:
tags:
- ruby
- postgres


上面的规范将确保
job
由一个具有两个
ruby
AND
postgres
标签的Runner构建。


allow_failure

allow_failure
当您要允许作业失败而不影响其余的CI套件时使用。失败的作业无助于提交状态。

启用并且作业失败时,对于所有意图和目的,流水线将成功/绿色,但是在合并请求或提交或作业页面上将显示“通过警告的CI构建”消息。这被允许失败的作业使用,但是如果失败表示其他地方应采取其他(手动)步骤。

在下面的示例中,
job1
并且
job2
将并行运行,但是如果
job1
失败,则不会停止运行的下一个阶段,因为它标记为
allow_failure:
true

job1:
stage: test
script:
- execute_script_that_will_fail
allow_failure: true

job2:
stage: test
script:
- execute_script_that_will_succeed

job3:
stage: deploy
script:
- deploy_to_staging


什么时候

when
用于实现在出现故障或运行失败时运行的作业。

when
可以设置为以下值之一:

on_success
-
只有当前一个阶段的所有工作成功时才​​执行工作。这是默认值。
on_failure
-
仅当前一个阶段的至少一个作业发生故障时才执行作业。
always
-
无论前一阶段的工作状况如何,执行工作。
manual
-
手动执行作业(在GitLab 8.10中添加)。阅读 下面的手动操作

例如:
stages:
- build
- cleanup_build
- test
- deploy
- cleanup

build_job:
stage: build
script:
- make build

cleanup_build_job:
stage: cleanup_build
script:
- cleanup build when failed
when: on_failure

test_job:
stage: test
script:
- make test

deploy_job:
stage: deploy
script:
- make deploy
when: manual

cleanup_job:
stage: cleanup
script:
- cleanup after jobs
when: always


以上脚本将:

cleanup_build_job
仅在
build_job
失败时执行。
始终执行
cleanup_job
作为流水线的最后一步,无论成功或失败。
允许您
deploy_job
从GitLab的UI 手动执行。


手动操作

在GitLab 8.10中介绍。

手动操作是不自动执行的特殊类型的作业; 他们需要由用户明确地启动。可以从管道,构建,环境和部署视图启动手动操作。

手动操作的示例使用是部署到生产。

阅读更多在环境文档

手动操作可以是可选的或阻止的。阻止手动操作将在此操作定义的阶段阻止流水线的执行。当有人通过单击播放按钮执行阻止手动操作时,可以恢复管道的执行。

当管道被阻止时,如果管道成功设置时合并,则不会合并管道。封闭的管道也有一个特殊的状态,称为手动。

默认情况下,手动操作不阻止。如果要进行手动操作阻止,则需要添加
allow_failure:
false
到作业的定义中
.gitlab-ci.yml


allow_failure:
true
默认情况下,可选手动操作已设置。

可选操作的状态对总体管道状态无贡献。

GitLab 9.0中引入了禁止手动操作


环境

笔记:

在GitLab 8.9中引入。
你可以阅读更多有关的环境,并找到更多的例子 有关环境的文档

environment
用于定义作业部署到特定环境。如果
environment
被指定,并且没有该名称下的环境,则将自动创建一个新的名称。

在最简单的形式中,
environment
关键字可以定义如下:
deploy to production:
stage: deploy
script: git push production HEAD:master
environment:
name: production


在上述示例中,
deploy
to production
作业将被标记为对环境进行
production
部署。


环境:名称

笔记:

在GitLab 8.11中引入。
在GitLab 8.11之前,环境的名称可以被定义为一个字符串
environment:
production
。现在推荐的方法是在
name
关键字下定义它 。

environment
名称可以包含以下内容:

信件
数字
空格
-

_

/

$

{

}


通用名称是
qa
staging
production
,但您可以使用与工作流程相匹配的任何名称。

除了在
environment
关键字之后定义环境的名称之外,还可以将其定义为单独的值。为此,请使用以下
name
关键字
environment

deploy to production:
stage: deploy
script: git push production HEAD:master
environment:
name: production


环境:url

笔记:

在GitLab 8.11中引入。
在GitLab 8.11之前,该URL只能在GitLab的UI中添加。现在推荐的方法是定义它
.gitlab-ci.yml


这是一个可选的值,当设置时,它会暴露GitLab中各个位置的按钮,当单击时,您可以访问定义的URL。

在下面的示例中,如果作业成功完成,它将在合并请求和将指向的环境/部署页面中创建按钮
https://prod.example.com

deploy to production:
stage: deploy
script: git push production HEAD:master
environment:
name: productionurl: https://prod.example.com 


environment:on_stop

笔记:

介绍在GitLab 8.13。
从GitLab 8.14开始,当您有一个定义了停止动作的环境时,GitLab会在关联的分支被删除时自动触发停止动作。

关闭(stoping)环境可以通过下面
on_stop
定义的关键字 来实现
environment
。它宣布了一个不同的工作,以便关闭环境。

阅读本
environment:action
节为例。


环境:行动

介绍在GitLab 8.13。

action
关键字与
on_stop
被称为关闭环境的作业结合使用并定义。

例如:
review_app:
stage: deploy
script: make deploy-app
environment:
name: review
on_stop: stop_review_app

stop_review_app:
stage: deploy
script: make delete-app
when: manual
environment:
name: review
action: stop


在上面的例子中,我们设置了
review_app
部署到环境中的
review
工作,我们也定义了一个新的
stop_review_app
工作
on_stop
。一旦
review_app
作业成功完成,它将
stop_review_app
根据下面的定义触发 作业
when
。在这种情况下,我们设置它,
manual
因此需要通过GitLab的Web界面进行手动操作才能运行。

stop_review_app
作业需要定义以下关键字:

when
- 参考
environment:name

environment:action

stage
应该是相同的
review_app
,以便环境在分支被删除时自动停止


动态环境

笔记:

介绍在GitLab 8.12和GitLab亚军1.6。
$CI_ENVIRONMENT_SLUG
介绍在GitLab
8.15。

environment
也可以用
name
和表示一个配置哈希
url
。这些参数可以使用任何定义的CI变量 (包括预定义的安全变量和
.gitlab-ci.yml
变量)。

例如:
deploy as review app:
stage: deploy
script: make deploy
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_ENVIRONMENT_SLUG.example.com/


deploy
as review app
作业将被标记为部署以动态创建
review/$CI_COMMIT_REF_NAME
环境,其中由Runner设置
$CI_COMMIT_REF_NAME
环境变量在哪里。该
$CI_ENVIRONMENT_SLUG
变量基于环境名称,但适合包含在URL中。在这种情况下,如果
deploy
as review app
作业是在命名的分支中运行的
pow
,那么这个环境将可以通过一个URL访问
https://review-pow.example.com/


这当然意味着承载应用程序的底层服务器被正确配置。

常见的用例是为分支创建动态环境,并将其用作Review Apps。您可以在https://gitlab.com/gitlab-examples/review-apps-nginx/上查看使用Review
Apps的简单示例 。


文物

笔记:

在非Windows平台的GitLab Runner v0.7.0中引入。
GitLab Runner v.1.0.0中添加了Windows支持。
目前并不是所有的执行者都被支持。
默认情况下,作业工件仅针对成功的作业进行收集。

artifacts
用于指定成功后应附加到作业的文件和目录的列表。您只能使用项目工作区内的路径。要在不同的作业之间传递工件,请参阅依赖关系。以下是一些例子。

发送所有文件
binaries
.config

artifacts:
paths:
- binaries/
- .config


发送所有Git未跟踪的文件:
artifacts:
untracked: true


发送所有Git未跟踪的文件和文件
binaries

artifacts:
untracked: truepaths:
- binaries/


要禁用工件传递,请使用空的依赖关系定义作业:
job:
stage: build
script: make build
dependencies: []


您可能只想为标记的版本创建工件,以避免使用临时构建工件填充构建服务器存储。

仅为标签创建工件(
default-job
不会创建工件):
default-job:
script:
- mvn test -U
except:
- tags

release-job:
script:
- mvn package -U
artifacts:
paths:
- target/*.war
only:
- tags


工作完成后,工件将发送到GitLab,并可在GitLab UI中下载。


文物:名称

在GitLab 8.6和GitLab Runner v1.1.0中引入。

name
指令允许您定义创建的工件存档的名称。这样,您可以为每个存档提供一个唯一的名称,当您希望从GitLab下载存档时,这可能会很有用。该
artifacts:name
变量可以使用任何预定义的变量。默认名称为
artifacts
,成为
artifacts.zip
下载的时候。

示例配置

要创建具有当前作业名称的归档文件:
job:
artifacts:
name: "$CI_JOB_NAME"


要创建具有当前分支或标记的名称的归档文件,仅包含由Git未跟踪的文件:
job:
artifacts:
name: "$CI_COMMIT_REF_NAME"
untracked: true


要使用当前作业的名称创建一个存档,并且当前的分支或标记仅包含Git未跟踪的文件:
job:
artifacts:
name: "${CI_JOB_NAME}_${CI_COMMIT_REF_NAME}"
untracked: true


要创建具有当前阶段和分支名称的存档:
job:
artifacts:
name: "${CI_JOB_STAGE}_${CI_COMMIT_REF_NAME}"
untracked: true


如果您使用Windows Batch来运行您的shell脚本,则需要替换
$
%

job:
artifacts:
name: "%CI_JOB_STAGE%_%CI_COMMIT_REF_NAME%"
untracked: true


文物:何时

在GitLab 8.9和GitLab Runner v1.3.0中引入。

artifacts:when
用于在作业失败或尽管发生故障时上传工件。

artifacts:when
可以设置为以下值之一:

on_success
-
仅当作业成功时上传工件。这是默认值。
on_failure
-
仅当作业失败时才上传工件。
always
-
无论工作状态如何,都会上传工件。

示例配置

仅在作业失败时上传工件。
job:
artifacts:
when: on_failure


文物:expire_in

在GitLab 8.9和GitLab Runner v1.3.0中引入。

artifacts:expire_in
用于在指定时间后删除上传的工件。默认情况下,工件永远存储在GitLab上。
expire_in
允许您指定制品在其过期之前应存在多长时间,从上传和存储在GitLab上的时间开始计算。

您可以使用作业页面上的“ 保留 ”按钮来覆盖过期并永久保存工件。

到期后,默认情况下实际上会删除工件(通过cron作业),但在到期后不可访问。

expire_in
是经过的时间。可分析值的示例:

'3分4秒'
'2小时20分钟'
'2h20min'
'6 mos 1天'
'47年6 mos和4d'
'3周2天'

示例配置

上传后1周过期文物:
job:
artifacts:
expire_in: 1 week


依赖关系

在GitLab 8.6和GitLab Runner v1.1.1中引入。

此功能应与之结合使用,
artifacts
并允许您定义在不同作业之间传递的工件。

请注意,默认情况下
artifacts
,所有以前的阶段都将被传递。

要使用此功能,请
dependencies
在作业的上下文中定义,并传递所有以前作业的列表,从中下载工件。您只能从在当前执行的阶段定义作业。如果从当前阶段或下一个阶段定义作业,将会显示错误。定义空数组将跳过下载该作业的任何工件。

在下面的例子中,我们定义了两个就业机会,文物,
build:osx
build:linux
。当
test:osx
被执行时,从所述工件
build:osx
将被下载和在构建的上下文中提取。同样的事情
test:linux
和文物从
build:linux


deploy
由于阶段优先级,该作业将从以前所有作业中下载工件:
build:osx:
stage: build
script: make build:osx
artifacts:
paths:
- binaries/

build:linux:
stage: build
script: make build:linux
artifacts:
paths:
- binaries/

test:osx:
stage: test
script: make test:osx
dependencies:
- build:osx

test:linux:
stage: test
script: make test:linux
dependencies:
- build:linux

deploy:
stage: deploy
script: make deploy


before_script和after_script

可以覆盖全局定义的
before_script
after_script

before_script:
- global before script

job:
before_script:
- execute this instead of global before script
script:
- my command
after_script:
- execute this after my script


覆盖面

笔记:

介绍在GitLab 8.17。

coverage
允许您配置如何从作业输出中提取代码覆盖率。

正则表达式是这里唯一有效的值。所以,使用周边
/
是强制性的,以便一致地和明确地表示正则表达式字符串。如果你想从字面上匹配,你必须逃脱特殊字符。

一个简单的例子:
job1:
coverage: '/Code coverage: \d+\.\d+/'


Git策略

作为实验功能在GitLab 8.9中引入。在未来版本中可能会更改或完全删除。
GIT_STRATEGY=none
需要GitLab
Runner v1.7 +。

您可以
GIT_STRATEGY
在全局
variables
部分或
variables
单个作业的部分中设置用于获取最近的应用程序代码。如果未指定,将使用项目设置的默认值。

有三种可能的值:
clone
fetch
,和
none


clone
是最慢的选择。它为每个作业从头开始克隆资源库,确保项目工作区始终是原始的。
variables:
GIT_STRATEGY: clone


fetch
更快,因为它重新使用项目工作区(
clone
如果它不存在则回退)。
git
clean
用于撤消上一个作业所做的更改,并
git
fetch
用于检索自上次作业运行以来所做的提交。
variables:
GIT_STRATEGY: fetch


none
也重新使用项目工作区,但是跳过所有Git操作(包括GitLab
Runner的pre-clone脚本(如果存在))。它主要用于仅对工件(例如
deploy
)进行操作的作业。Git存储库数据可能存在,但它肯定是过期的,因此您只应该依赖从缓存或工件引入项目工作空间的文件。
variables:
GIT_STRATEGY: none


Git子模块策略

需要GitLab Runner v1.10 +。

GIT_SUBMODULE_STRATEGY
变量用于在构建之前获取代码时控制是否/如何包含Git子模块。喜欢
GIT_STRATEGY
,可以在全局
variables
部分或
variables
单个作业的部分中设置。

有三种可能的值:
none
normal
recursive


none
意味着在获取项目代码时不会包含子模块。这是默认值,它与v1.10之前的行为相匹配。

normal
意味着只包括顶级子模块。相当于:
git submodule sync
git submodule update --init


recursive
意味着将包括所有子模块(包括子模块子模块)。相当于:
git submodule sync --recursive
git submodule update --init --recursive


请注意,要使此功能正常工作,子模块必须
.gitmodules
配置为:

可公开访问的存储库的HTTP(S)URL
在同一个GitLab服务器上的另一个存储库的相对路径。请参阅 Git子模块文档。


作业阶段尝试

在GitLab中引入,它需要GitLab Runner v1.9 +。

您可以设置运行作业将尝试执行以下每个阶段的尝试次数:
变量描述
GET_SOURCES_ATTEMPTS尝试获取运行作业的源的次数
ARTIFACT_DOWNLOAD_ATTEMPTS尝试下载运行作业的工件的次数
RESTORE_CACHE_ATTEMPTS尝试恢复运行作业的缓存的次数
默认是一次尝试。

例:
variables:
GET_SOURCES_ATTEMPTS: "3"


您可以在全局
variables
部分或
variables
单个作业的 部分中进行设置。


浅克隆

作为实验功能在GitLab 8.9中引入。可能会在未来版本中更改或完全删除。

您可以使用指定抓取和克隆的深度
GIT_DEPTH
。这允许浅层克隆存储库,这可以显着加速具有大量提交或旧的大型二进制文件的存储库的克隆。该值传递给
git
fetch
git
clone


注意: 如果深度为1,并且具有作业队列或重试作业,作业可能会失败。

由于Git获取和克隆是基于一个引用(如分支名称),所以Runners不能克隆特定的提交SHA。如果队列中有多个作业,或者您正在重试旧作业,则要测试的提交需要在克隆的Git历史记录中。设置太小的值
GIT_DEPTH
可能导致无法运行这些旧的提交。您将
unresolved
reference
在作业日志中看到。然后,您应该重新考虑更改
GIT_DEPTH
为更高的值。

由于只有Git历史的一部分存在,依赖的作业
git
describe
可能无法正常工作
GIT_DEPTH


仅获取或克隆最近3次提交:
variables:
GIT_DEPTH: "3"


隐藏键

在GitLab 8.6和GitLab Runner v1.1.1中引入。

以点(
.
)开头的键不会被GitLab
CI处理。您可以使用此功能忽略作业,或使用 特殊的YAML功能,并将隐藏的键转换为模板。

在以下示例中,
.key_name
将被忽略:
.key_name:
script:
- rake spec


隐藏的键可以像普通CI作业一样散列,但是您也可以使用不同类型的结构来利用特殊的YAML功能。


特殊YAML功能

可以使用特殊的YAML功能,如anchor(
&
),别名(
*
)和map
merging(
<<
),这将大大降低复杂度
.gitlab-ci.yml


详细了解各种YAML功能


锚点

在GitLab 8.6和GitLab Runner v1.1.1中引入。

YAML有一个方便的功能,称为“锚”,可以让您轻松地在文档中复制内容。锚可用于复制/继承属性,并且是使用隐藏键 来为您的作业提供模板的完美示例。

以下示例使用锚点和地图合并。它会创建两个就业机会,
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


我们来看另一个例子。这一次我们将使用anchor来定义两组服务。这将创建两个作业,
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


您可以看到隐藏的键被方便地用作模板。


触发器

触发器可用于强制使用API​​调用重建特定分支,标记或提交。

在触发器文档中阅读更多内容。


页面

pages
是一个特殊的工作,用于将静态内容上传到GitLab,可用于为您的网站提供服务。它具有特殊的语法,因此必须满足以下两个要求:

任何静态内容必须放在
public/
目录下
artifacts
public/
必须定义到目录的路径

下面的示例将所有文件从项目的根移动到
public/
目录。该
.public
解决方法是这样
cp
不也复制
public/
到自身无限循环:
pages:
stage: deploy
script:
- mkdir .public
- cp -r * .public
- mv .public public
artifacts:
paths:
- public
only:
- master


阅读更多关于GitLab Pages用户文档


验证.gitlab-ci.yml

GitLab CI的每个实例都有一个名为Lint的嵌入式调试工具。您可以在
/ci/lint
gitlab实例下找到链接。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  自动化部署