gitlab-ci之yml

 官方文档：https://docs.gitlab.com/ee/ci/quick_start/README.html

 

GitLab提供持续集成服务。如果 将.gitlab-ci.yml文件添加到存储库的根目录，并将GitLab项目配置为使用Runner，则每次提交或推送都会触发CI 管道。

该.gitlab-ci.yml文件告诉GitLab跑步者该做什么。默认情况下，它运行有三个流水线阶段：build，test，和deploy。你不需要使用所有三个阶段; 没有工作的阶段被忽略了。

如果一切运行正常（没有非零返回值），您将获得与提交相关联的漂亮绿色复选标记。这样可以在查看代码之前轻松查看提交是否导致任何测试失败。

大多数项目使用GitLab的CI服务来运行测试套件，以便开发人员在破坏某些内容时立即获得反馈。

使用持续交付和持续部署将测试代码自动部署到登台和生产环境的趋势越来越明显。

简而言之，具有工作CI所需的步骤可归纳为：

1. 添加.gitlab-ci.yml到存储库的根目录
2. 配置一个Runner

从那时起，在每次推送到Git存储库时，Runner将自动启动管道，管道将显示在项目的Pipelines页面下。

工作 

YAML文件定义了一组具有约束的作业，说明应该何时运行它们。您可以指定无限数量的作业，这些作业被定义为具有任意名称的顶级元素，并且始终必须至少包含该script子句。

job1:
  script: "execute-script-for-job1"

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

上面的示例是最简单的CI / CD配置，具有两个单独的作业，其中每个作业执行不同的命令。当然，命令可以直接执行代码（./configure;make;make install）或test.sh在存储库中运行脚本（）。

跑步者选择工作并在跑步者的环境中执行。重要的是，每项工作都是相互独立运作的。

每个作业必须具有唯一的名称，但有一些保留keywords不能用作作业名称：

• image
• services
• stages
• types
• before_script
• after_script
• variables
• cache

作业由定义作业行为的参数列表定义。

关键词	需要	描述
脚本	是	定义由Runner执行的shell脚本
图片	没有	使用Docker镜像，使用Docker Images进行了介绍
服务	没有	使用Docker服务，使用Docker Images
阶段	没有	定义一个工作阶段（默认：test）
类型	没有	别名为 stage
变量	没有	在作业级别定义作业变量
只要	没有	定义为其创建作业的git refs列表
除	没有	定义未创建作业的git refs列表
标签	没有	定义用于选择Runner的标记列表
allow_failure	没有	让工作失败。失败的作业无助于提交状态
什么时候	没有	定义何时运行作业。可以是on_success，on_failure，always或者manual
依赖	没有	定义作业所依赖的其他作业，以便您可以在它们之间传递工件
文物	没有	定义作业工件列表
高速缓存	没有	定义后续运行之间应缓存的文件列表
before_script	没有	覆盖在作业之前执行的一组命令
after_script	没有	覆盖作业后执行的一组命令
环境	没有	定义此作业完成部署的环境名称
覆盖	没有	定义给定作业的代码覆盖率设置
重试	没有	定义在发生故障时可以自动重试作业的次数

pages 

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

1. 任何静态内容都必须放在public/目录下
2. artifactspublic/必须定义目录的路径

下面的示例只是将项目根目录中的所有文件移动到 public/目录中。该.public解决方法是这样cp不也复制 public/到自身无限循环：

pages:
  stage: deploy
  script:
    - mkdir .public
    - cp -r * .public
    - mv .public public
  artifacts:
    paths:
      - public
  only:
    - master

阅读GitLab Pages用户文档的更多信息。

image 和 services 

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

before_script 和 after_script 

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

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

after_script用于定义将在所有作业（包括失败作业）之后运行的命令。这必须是数组或多行字符串。

的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 command
  after_script:
    - execute this after my script

stages 

stages 用于定义可由作业使用的阶段，并且是全局定义的。

规范stages允许具有灵活的多级管道。元素stages的排序定义了作业执行的顺序：

1. 同一阶段的工作是并行运行的。
2. 下一阶段的作业在上一阶段的作业成功完成后运行。

让我们考虑以下示例，它定义了3个阶段：

stages:
  - build
  - test
  - deploy

1. 首先，所有工作build都是并行执行的。
2. 如果所有作业都build成功，则test作业将并行执行。
3. 如果所有作业都test成功，则deploy作业将并行执行。
4. 如果所有作业都deploy成功，则提交标记为passed。
5. 如果任何先前的作业失败，则将提交标记为，failed并且不执行其他阶段的作业。

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

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

stage 

stage是按工作定义的，依赖于stages全局定义的。它允许将作业分组到不同的阶段，并stage执行相同的作业 parallel。例如：

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 

不 types推荐使用：已弃用，可以在以后的某个版本中删除。而是使用阶段。

script 

script是作业所需的唯一必需关键字。这是一个由Runner执行的shell脚本。例如：

job:
  script: "bundle exec rspec"

此参数还可以包含使用数组的多个命令：

job:
  script:
    - uname -a
    - bundle exec rspec

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

only和except（简化）

only并且except是两个参数，用于将作业策略设置为在创建作业时进行限制：

1. only 定义作业将运行的分支和标记的名称。
2. except定义作业不会运行的分支和标记的名称 。

有一些适用于工作政策的规则：

• only并且except是包容性的。如果同时only并except在作业规范中定义，裁判通过过滤only和except。
• only并except允许使用正则表达式。
• only并except允许指定用于过滤forks作业的存储库路径。

另外，only并except允许使用特殊关键字：

值	描述
branches	当推动分支时。
tags	推送标签时。
api	当管道由第二个管道API（不是触发器API）触发时。
external	使用GitLab以外的CI服务时。
pipelines	对于使用API​​创建的多项目触发器CI_JOB_TOKEN。
pushes	管道git push由用户触发。
schedules	对于预定的管道。
triggers	对于使用触发器令牌创建的管道。
web	对于使用GitLab UI中的“运行管道”按钮创建的管道（在项目的管道下）。

在下面的示例中，job将仅针对以＃开头的ref运行issue-，而将跳过所有分支：

job:
  # use regexp
  only:
    - /^issue-.*$/
  # use special keyword
  except:
    - branches

在此示例中，job将仅针对已标记的引用运行，或者通过API触发器或管道调度显式请求构建：

job:
  # use special keywords
  only:
    - tags
    - triggers
    - schedules

存储库路径可用于仅为父存储库而不是forks执行作业：

job:
  only:
    - branches@gitlab-org/gitlab-ce
  except:
    - master@gitlab-org/gitlab-ce

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

only和except（复杂的）

refs和kubernetesGitLab 10.0中引入的策略

variables 政策在10.7中引入

警告： 这是一个alpha功能，它可能随时更改，恕不另行通知！

从GitLab 10.0开始，可以定义更精细的only / except作业策略配置。

GitLab现在支持简单和复杂的策略，因此可以使用数组和哈希配置方案。

三个键现在可供选择：refs，kubernetes和variables。Refs策略等于仅简化/除配置，而kubernetes策略仅接受active关键字。

variableskeyword用于定义变量表达式。换句话说，您可以使用预定义变量/项目/组或环境范围变量来定义GitLab将要评估的表达式，以决定是否应创建作业。

请参阅下面的示例。只有在为master分支调度或运行管道时才会创建作业，并且只有在项目中kubernetes服务处于活动状态时才会创建作业。

job:
  only:
    refs:
      - master
      - schedules
    kubernetes: active

使用变量表达式的示例：

deploy:
  script: cap staging deploy
  only:
    refs:
      - branches
    variables:
      - $RELEASE == "staging"
      - $STAGING

另一个用例是根据提交消息（在11.0中添加）来排除作业：

end-to-end:
  script: rake test:end-to-end
  except:
    variables:
      - $CI_COMMIT_MESSAGE =~ /skip-end-to-end-tests/

在单独的页面上详细了解变量表达式。

tags 

tags 用于从允许运行此项目的所有运行程序列表中选择特定的运行程序。

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

tags 允许您使用分配了指定标记的Runners运行作业：

job:
  tags:
    - ruby
    - postgres

上面的规范将确保job由同时定义了rubyAND 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 用于实现在发生故障或尽管发生故障时运行的作业。

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

1. on_success - 只有当前几个阶段的所有工作都成功时才执行工作。这是默认值。
2. on_failure - 仅当前一阶段的至少一个作业失败时才执行作业。
3. always - 无论先前阶段的工作状态如何，都可以执行工作。
4. 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

上面的脚本将：

1. cleanup_build_job仅在build_job失败时执行。
2. cleanup_job无论成功与否，始终作为管道的最后一步执行。
3. 允许您deploy_job从GitLab的UI 手动执行。

when:manual 

笔记：

• 在GitLab 8.10中引入。
• 阻止手动操作在GitLab 9.0中引入。
• 受保护的操作在GitLab 9.2中引入。

手动操作是一种特殊类型的作业，不会自动执行，需要由用户明确启动。手动操作的示例用法是部署到生产环境。可以从管道，作业，环境和部署视图启动手动操作。阅读环境文档中的更多 内容。

手动操作可以是可选的也可以是阻止的。阻止手动操作将在定义此操作的阶段阻止管道的执行。当有人通过单击播放按钮执行阻止手动操作时，可以继续执行管道。

管道被阻止时，如果设置了合并管道成功，则不会合并。被阻止的管道也有一个特殊的状态，称为手动。默认情况下，手动操作是非阻止的。如果要阻止手动操作，则需要添加allow_failure: false到作业的定义中.gitlab-ci.yml。

allow_failure: true默认情况下已设置可选的手动操作，其状态不会影响整个管道状态。因此，如果手动操作失败，管道最终将成功。

手动操作被视为写入操作，因此当用户想要触发操作时，将使用受保护分支的权限 。换句话说，为了触发分配给管道正在运行的分支的手动操作，用户需要具有合并到该分支的能力。

environment 

笔记：

• 在GitLab 8.9中引入。
• 您可以阅读有关环境的更多信息，并在有关环境的文档中查找更多示例 。

environment用于定义作业部署到特定环境。如果environment已指定且该名称下不存在任何环境，则将自动创建一个新环境。

在最简单的形式中，environment关键字可以定义为：

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

在上面的示例中，deploy to production作业将标记为对production环境进行部署。

environment:name 

笔记：

• 在GitLab 8.11中引入。
• 在GitLab 8.11之前，可以将环境的名称定义为类似的字符串 environment: production。现在推荐的方法是在name关键字下定义它 。
• 该name参数可以使用任何已定义的CI变量，包括预定义的安全变量和.gitlab-ci.yml variables。但是，您无法使用下面定义的变量script。

该environment名称可以包含以下内容：

• 信
• 数字
• 空间
• -
• _
• /
• $
• {
• }

通用名称是qa,, staging和production，但您可以使用适用于您的工作流程的任何名称。

不是在environment 关键字之后定义环境的名称，而是可以将其定义为单独的值。为此，请使用以下name关键字environment：

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

environment:url 

笔记：

• 在GitLab 8.11中引入。
• 在GitLab 8.11之前，只能在GitLab的UI中添加URL。现在推荐的方法是定义它.gitlab-ci.yml。
• 该url参数可以使用任何已定义的CI变量，包括预定义的安全变量和.gitlab-ci.yml variables。但是，您无法使用下面定义的变量script。

这是一个可选值，在设置时，它会在GitLab中的各个位置公开按钮，单击这些按钮会转到定义的URL。

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

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

environment:on_stop 

笔记：

• 在GitLab 8.13中引入。
• 从GitLab 8.14开始，如果您的环境定义了停止操作，GitLab将在删除关联分支时自动触发停止操作。

可以使用下面on_stop定义的关键字 实现关闭（停止）环境environment。它声明了一个不同的工作，以便关闭环境。

阅读本environment:action节的示例。

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 Runner 1.6中引入。
• 这$CI_ENVIRONMENT_SLUG是在GitLab 8.15 中引入的。
• 的name和url参数可以使用任何已定义的CI变量，包括预定义的，安全的变量和的.gitlab-ci.yml variables。但是，您无法使用下面定义的变量script。

例如：

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环境中，$CI_COMMIT_REF_NAME 是一个环境变量被设置亚军。该 $CI_ENVIRONMENT_SLUG变量基于环境名称，但适合包含在URL中。在这种情况下，如果deploy as review app作业是在名为的分支中运行的，则pow可以使用URL来访问此环境 https://review-pow.example.com/。

这当然意味着正确配置了托管应用程序的底层服务器。

常见用例是为分支创建动态环境并将其用作评论应用程序。您可以通过https://gitlab.com/gitlab-examples/review-apps-nginx/查看使用评论应用程序的简单示例 。

cache 

笔记：

• 在GitLab Runner v0.7.0中引入。
• cache 可以全局和按工作设置。
• 从GitLab 9.0开始，默认情况下启用缓存并在管道和作业之间共享。
• 从GitLab 9.2开始，在工件之前恢复缓存。

了解更多： 了解缓存的工作原理，并在缓存依赖项文档中找到一些好的实践 。

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

如果cache在作业范围之外定义，则表示它是全局设置的，并且所有作业都将使用该定义。

cache:paths 

使用该paths指令选择要缓存的文件或目录。也可以使用通配符。

缓存binaries该端的所有文件.apk和.config文件：

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

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

cache:
  paths:
    - my/files

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

请注意，由于缓存是在作业之间共享的，如果您对不同的作业使用不同的路径，则还应设置不同的缓存：key， 否则可以覆盖缓存内容。

cache:key 

在GitLab Runner v1.0.0中引入。

由于缓存是在作业之间共享的，如果您对不同的作业使用不同的路径，则还应设置不同的cache:key 其他缓存内容，否则可以覆盖。

该key指令允许您定义作业之间的缓存关联，允许为所有作业提供单个缓存，每个作业缓存，每个分支缓存或适合您的工作流的任何其他方式。这样，您可以微调缓存，允许您在不同作业甚至不同分支之间缓存数据。

该cache:key变量可以使用任何 预定义变量，默认密钥（如果未设置）只是文字default，这意味着默认情况下，从GitLab 9.0开始，每个管道和作业之间共享所有内容。

注意： 该cache:key变量不能包含/字符，或等效的URI编码%2F; 仅禁用点（.，%2E）的值也是禁止的。

例如，要启用每分支缓存：

cache:
  key: "$CI_COMMIT_REF_SLUG"
  paths:
    - binaries/

如果使用Windows Batch运行shell脚本，则需要替换 $为%：

cache:
  key: "%CI_COMMIT_REF_SLUG%"
  paths:
    - binaries/

cache:untracked 

设置untracked: true为缓存Git存储库中未跟踪的所有文件：

rspec:
  script: test
  cache:
    untracked: true

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

rspec:
  script: test
  cache:
    untracked: true
    paths:
      - binaries/

cache:policy 

在GitLab 9.4中引入。

缓存作业的默认行为是在执行开始时下载文件，并在结束时重新上载它们。这允许将作业所做的任何更改保留以供将来运行，并称为pull-push缓存策略。

如果您知道作业未更改高速缓存的文件，则可以通过policy: pull在作业规范中进行设置来跳过上载步骤。通常，这将在较早阶段与普通缓存作业配对，以确保缓存不时更新：

stages:
  - setup
  - test

prepare:
  stage: setup
  cache:
    key: gems
    paths:
      - vendor/bundle
  script:
    - bundle install --deployment

rspec:
  stage: test
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - bundle exec rspec ...

这有助于加快作业执行速度并减少缓存服务器上的负载，尤其是当您有大量并行执行缓存的作业时。

此外，如果您的作业无条件地重新创建缓存而不参考其先前的内容，则可以policy: push在该作业中使用跳过下载步骤。

artifacts 

笔记：

• 适用于非Windows平台的GitLab Runner v0.7.0中引入。
• 在GitLab Runner v.1.0.0中添加了Windows支持。
• 从GitLab 9.2开始，在工件之前恢复缓存。
• 并非所有执行程序都受支持。
• 默认情况下，仅为成功作业收集作业工件。

artifacts 用于指定成功后应附加到作业的文件和目录列表。

作业成功完成后，工件将被发送到GitLab，并可在GitLab UI中下载。

阅读有关工件的更多信息。

artifacts:paths 

您只能使用项目工作区内的路径。要在不同作业之间传递工件，请参阅依赖项。

发送所有文件binaries和.config：

artifacts:
  paths:
    - binaries/
    - .config

要禁用工件传递，请使用空依赖关系定义作业：

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

artifacts:name 

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

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

注意： 如果您的分支名称包含正斜杠（例如feature/my-feature），则建议使用$CI_COMMIT_REF_SLUG 而不是$CI_COMMIT_REF_NAME正确命名工件。

要创建具有当前作业名称的存档：

job:
  artifacts:
    name: "$CI_JOB_NAME"
    paths:
      - binaries/

要创建包含当前分支或标记名称的归档，仅包含二进制目录：

job:
   artifacts:
     name: "$CI_COMMIT_REF_NAME"
    paths:
      - binaries/

要创建具有当前作业名称的存档以及仅包含二进制目录的当前分支或标记：

job:
  artifacts:
    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    paths:
      - binaries/

要创建具有当前阶段和分支名称的名称的存档：

job:
  artifacts:
    name: "$CI_JOB_STAGE-$CI_COMMIT_REF_NAME"
    paths:
      - binaries/

---

如果使用Windows Batch运行shell脚本，则需要替换 $为%：

job:
  artifacts:
    name: "%CI_JOB_STAGE%-%CI_COMMIT_REF_NAME%"
    paths:
      - binaries/

如果使用Windows PowerShell运行shell脚本，则需要替换 $为$env:：

job:
  artifacts:
    name: "$env:CI_JOB_STAGE-$env:CI_COMMIT_REF_NAME"
    paths:
      - binaries/

artifacts:untracked 

artifacts:untracked用于将所有Git未跟踪文件添加为工件（沿着定义的路径artifacts:paths）。

注意： 要排除不应将其untracked添加到的文件夹/文件.gitignore。

发送所有Git未跟踪文件：

artifacts:
  untracked: true

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

artifacts:
  untracked: true
  paths:
    - binaries/

artifacts:when 

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

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

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

1. on_success - 仅在作业成功时上载工件。这是默认值。
2. on_failure - 仅在作业失败时上传工件。
3. always - 无论作业状态如何，都上传工件。

仅在作业失败时上载工件：

job:
  artifacts:
    when: on_failure

artifacts:expire_in 

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

expire_in允许您指定工件在到期之前应该存在多长时间并因此被删除，从它们上载和存储在GitLab上的时间开始计算。如果未定义到期时间，则默认为实例范围设置 （默认为 30天，永远在GitLab.com上）。

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

到期后，默认情况下每小时删除工件（通过cron作业），并且不再可访问工件。

值expire_in是经过的时间。可解析值的示例：

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

在上传1周后过期文物：

job:
  artifacts:
    expire_in: 1 week

dependencies 

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

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

请注意，默认情况下会传递artifacts所有先前阶段。

要使用此功能，请dependencies在作业的上下文中定义，并传递应从中下载工件的所有先前作业的列表。您只能从当前执行之前执行的阶段定义作业。如果您从当前阶段或下一阶段定义作业，将显示错误。定义空数组将跳过下载该作业的任何工件。使用时不考虑上一个作业的状态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

当依赖作业失败时 

在GitLab 10.3中引入。

如果作为依赖项的作业的工件已 过期或已 擦除，则相关作业将失败。

注意： 您可以要求管理员 翻转此开关 并恢复旧的行为。

coverage 

在GitLab 8.17中引入。

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

正则表达式是此处唯一有效的值。因此，使用around /是必需的，以便始终如一地明确表示正则表达式字符串。如果要按字面意思匹配它们，则必须转义特殊字符。

一个简单的例子：

job1:
  script: rspec
  coverage: '/Code coverage: \d+\.\d+/'

retry 

在GitLab 9.5中引入。

retry 允许您配置在发生故障时重试作业的次数。

当作业失败并且已retry配置时，它将再次处理，直到retry关键字指定的次数。

如果retry设置为2，并且作业在第二次运行（第一次重试）中成功，则不会再次重试。retryvalue必须是一个正整数，等于或大于0，但小于或等于2（最多两次重试，总共三次运行）。

一个简单的例子：

test:
  script: rspec
  retry: 2

include

起动机

青铜

 

在GitLab Edition Premium 10.5中引入。适用于10.6以来的Starter，Premium和Ultimate 版本。在GitLab 10.8中扩展了行为，以允许更灵活的覆盖

使用该include关键字，您可以允许包含外部YAML文件。

在以下示例中，.before-script-template.yml将自动提取和评估内容以及以下内容.gitlab-ci.yml：

# Content of https://gitlab.com/awesome-project/raw/master/.before-script-template.yml

before_script:
  - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
  - gem install bundler --no-ri --no-rdoc
  - bundle install --jobs $(nproc)  "${FLAGS[@]}"

# Content of .gitlab-ci.yml

include: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'

rspec:
  script:
    - bundle exec rspec

您可以将其定义为单个字符串，或者，如果要包含多个文件，则可以将其定义为不同值的数组。以下示例均为有效案例：

# Single string

include: '/templates/.after-script-template.yml'

# Array

include:
  - 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
  - '/templates/.after-script-template.yml'

---

include 支持两种类型的文件：

• 相同存储库的本地，通过使用同一存储库中的完整路径引用，/作为根目录。例如：

  # Within the repository
  include: '/templates/.gitlab-ci-template.yml'
  

  注意： 您只能在配置文件所在的同一分支上使用Git当前跟踪的文件。换句话说，在使用本地文件时，请确保两者.gitlab-ci.yml和本地文件位于同一分支上。

  注意： 我们不支持通过Git子模块路径包含本地文件。

• 远程位于不同位置，使用HTTP / HTTPS访问，使用完整URL引用。例如：

  include: 'https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml'
  

  注意： 远程文件必须通过简单的GET请求公开访问，因为我们不支持远程URL中的身份验证模式。

---

由于GitLab 10.8我们现在递归合并中定义的文件include 有那些.gitlab-ci.yml。无论关键字的位置如何，include始终首先评估定义的文件并递归地与内容合并。您可以利用递归合并来自定义和覆盖包含的CI配置中的详细信息以及本地定义。.gitlab-ci.ymlinclude

以下示例显示了特定的YAML定义的变量以及production正在自定义的包含文件中的作业详细信息 .gitlab-ci.yml。

# Content of https://company.com/autodevops-template.yml

variables:
  POSTGRES_USER: user
  POSTGRES_PASSWORD: testing_password
  POSTGRES_DB: $CI_ENVIRONMENT_SLUG

production:
  stage: production
  script:
    - install_dependencies
    - deploy
  environment:
    name: production
    url: https://$CI_PROJECT_PATH_SLUG.$AUTO_DEVOPS_DOMAIN
  only:
    - master

# Content of .gitlab-ci.yml

include: 'https://company.com/autodevops-template.yml'

image: alpine:latest

variables:
  POSTGRES_USER: root
  POSTGRES_PASSWORD: secure_password

stages:
  - build
  - test
  - production

production:
  environment:
    url: https://domain.com

在这种情况下，变量POSTGRES_USER以及定义POSTGRES_PASSWORD的production作业 的环境URL autodevops-template.yml已被中定义的新值覆盖 .gitlab-ci.yml。

注意： 不支持递归包含，这意味着您的外部文件不应使用该include关键字，因为它将被忽略。

递归合并允许您扩展和覆盖字典映射，但不能向包含的数组添加或修改项目。例如，要将其他项添加到生产作业脚本，必须重复现有的脚本项。

# Content of https://company.com/autodevops-template.yml

production:
  stage: production
  script:
    - install_dependencies
    - deploy

# Content of .gitlab-ci.yml

include: 'https://company.com/autodevops-template.yml'

stages:
  - production

production:
  script:
    - install_depedencies
    - deploy
    - notify_owner

在这种情况下，如果install_dependencies并且deploy没有重复 .gitlab-ci.yml，则它们将不是production 组合CI配置中作业的脚本的一部分。

注意： 我们目前不支持在源自的不同YAML文件中使用YAML别名include。您只能在同一文件中引用别名。

variables 

在GitLab Runner v0.5.0中引入。

注意： 整数（以及字符串）对于变量的名称和值都是合法的。浮动不合法，不能使用。

GitLab CI / CD允许您定义内部变量.gitlab-ci.yml，然后在作业环境中传递。它们可以在全局和按作业设置。在variables作业级别使用关键字时，它将覆盖全局YAML变量和预定义变量。

它们存储在Git存储库中，用于存储非敏感项目配置，例如：

variables:
  DATABASE_URL: "postgres://postgres@postgres/my_database"

这些变量稍后可用于所有已执行的命令和脚本。YAML定义的变量也设置为所有创建的服务容器，从而允许对它们进行微调。

要关闭特定作业中的全局定义变量，请定义空哈希：

job_name:
  variables: {}

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

详细了解变量及其优先级。

Git策略 

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

您可以GIT_STRATEGY在本variables节中设置用于获取最新应用程序代码的全局或每个作业。如果未指定，将使用项目设置的默认值。

有三种可能的值：clone，fetch，和none。

clone是最慢的选择。它从头开始为每个作业克隆存储库，确保项目工作区始终保持原始状态。

variables:
  GIT_STRATEGY: clone

fetch重新使用项目工作区时更快（clone 如果它不存在则回落）。git clean用于撤消上一个作业所做的任何更改，并git fetch用于检索自上次作业运行以来所做的提交。

variables:
  GIT_STRATEGY: fetch

none还重新使用项目工作区，但跳过所有Git操作（包括GitLab Runner的预克隆脚本，如果存在）。它主要用于专门用于工件的作业（例如deploy）。Git存储库数据可能存在，但肯定会过时，因此您应该只依赖从缓存或工件带入项目工作区的文件。

variables:
  GIT_STRATEGY: none