gitlab-ci之yml

最新推荐文章于 2024-02-05 17:59:11 发布
最新推荐文章于 2024-02-05 17:59:11 发布
阅读量6.1k 收藏 1
点赞数
分类专栏： gitlab持续集成

 官方文档：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子句。

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job1</span>:
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">"</span><span style="color:#a3be8c">execute-script-for-job1"</span>

<span style="color:#8fa1b3">job2</span>:
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">"</span><span style="color:#a3be8c">execute-script-for-job2"</span>
</code></span></span>

上面的示例是最简单的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/到自身无限循环：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">pages</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">deploy</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">mkdir .public</span>
    - <span style="color:#a3be8c">cp -r * .public</span>
    - <span style="color:#a3be8c">mv .public public</span>
  <span style="color:#8fa1b3">artifacts</span>:
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">public</span>
  <span style="color:#8fa1b3">only</span>:
    - <span style="color:#a3be8c">master</span>
</code></span></span>

阅读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 如果您按工作设置它：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">before_script</span>:
  - <span style="color:#a3be8c">global before script</span>

<span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">before_script</span>:
    - <span style="color:#a3be8c">execute this instead of global before script</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">my command</span>
  <span style="color:#8fa1b3">after_script</span>:
    - <span style="color:#a3be8c">execute this after my script</span>
</code></span></span>

stages 

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

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

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

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">stages</span>:
  - <span style="color:#a3be8c">build</span>
  - <span style="color:#a3be8c">test</span>
  - <span style="color:#a3be8c">deploy</span>
</code></span></span>
  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。例如：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">stages</span>:
  - <span style="color:#a3be8c">build</span>
  - <span style="color:#a3be8c">test</span>
  - <span style="color:#a3be8c">deploy</span>

<span style="color:#8fa1b3">job 1</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">build</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make build dependencies</span>

<span style="color:#8fa1b3">job 2</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">build</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make build artifacts</span>

<span style="color:#8fa1b3">job 3</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">test</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make test</span>

<span style="color:#8fa1b3">job 4</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">deploy</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make deploy</span>
</code></span></span>

types 

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

script 

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">"</span><span style="color:#a3be8c">bundle</span> <span style="color:#a3be8c">exec</span> <span style="color:#a3be8c">rspec"</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">uname -a</span>
    - <span style="color:#a3be8c">bundle exec rspec</span>
</code></span></span>

有时，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-，而将跳过所有分支：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#65737e"># use regexp</span>
  <span style="color:#8fa1b3">only</span>:
    - <span style="color:#a3be8c">/^issue-.*$/</span>
  <span style="color:#65737e"># use special keyword</span>
  <span style="color:#8fa1b3">except</span>:
    - <span style="color:#a3be8c">branches</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#65737e"># use special keywords</span>
  <span style="color:#8fa1b3">only</span>:
    - <span style="color:#a3be8c">tags</span>
    - <span style="color:#a3be8c">triggers</span>
    - <span style="color:#a3be8c">schedules</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">only</span>:
    - <span style="color:#a3be8c">branches@gitlab-org/gitlab-ce</span>
  <span style="color:#8fa1b3">except</span>:
    - <span style="color:#a3be8c">master@gitlab-org/gitlab-ce</span>
</code></span></span>

以上示例将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服务处于活动状态时才会创建作业。

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">only</span>:
    <span style="color:#8fa1b3">refs</span>:
      - <span style="color:#a3be8c">master</span>
      - <span style="color:#a3be8c">schedules</span>
    <span style="color:#8fa1b3">kubernetes</span>: <span style="color:#a3be8c">active</span>
</code></span></span>

使用变量表达式的示例：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">deploy</span>:
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">cap staging deploy</span>
  <span style="color:#8fa1b3">only</span>:
    <span style="color:#8fa1b3">refs</span>:
      - <span style="color:#a3be8c">branches</span>
    <span style="color:#8fa1b3">variables</span>:
      - <span style="color:#a3be8c">$RELEASE == "staging"</span>
      - <span style="color:#a3be8c">$STAGING</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">end-to-end</span>:
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">rake test:end-to-end</span>
  <span style="color:#8fa1b3">except</span>:
    <span style="color:#8fa1b3">variables</span>:
      - <span style="color:#a3be8c">$CI_COMMIT_MESSAGE =~ /skip-end-to-end-tests/</span>
</code></span></span>

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

tags 

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

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

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">tags</span>:
    - <span style="color:#a3be8c">ruby</span>
    - <span style="color:#a3be8c">postgres</span>
</code></span></span>

上面的规范将确保job由同时定义了rubyAND postgres标记的Runner构建。

allow_failure 

allow_failure当您希望允许作业失败而不影响CI套件的其余部分时使用。失败的作业不会影响提交状态。

启用并且作业失败后，管道将成功/绿色用于所有意图和目的，但在合并请求或提交或作业页面上将显示“带有警告的CI构建”消息。这将被允许失败的作业使用，但失败表明应在其他地方采取其他一些（手动）步骤。

在下面的例子中，job1并job2会并行运行，但是如果job1 失败了，也不会停止运行的下一个阶段，因为它标有 allow_failure: true：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job1</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">test</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">execute_script_that_will_fail</span>
  <span style="color:#8fa1b3">allow_failure</span>: <span style="color:#bf616a">true</span>

<span style="color:#8fa1b3">job2</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">test</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">execute_script_that_will_succeed</span>

<span style="color:#8fa1b3">job3</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">deploy</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">deploy_to_staging</span>
</code></span></span>

when 

when 用于实现在发生故障或尽管发生故障时运行的作业。

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

  1. on_success - 只有当前几个阶段的所有工作都成功时才执行工作。这是默认值。
  2. on_failure - 仅当前一阶段的至少一个作业失败时才执行作业。
  3. always - 无论先前阶段的工作状态如何，都可以执行工作。
  4. manual - 手动执行作业（在GitLab 8.10中添加）。阅读 下面的手动操作。

例如：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">stages</span>:
  - <span style="color:#a3be8c">build</span>
  - <span style="color:#a3be8c">cleanup_build</span>
  - <span style="color:#a3be8c">test</span>
  - <span style="color:#a3be8c">deploy</span>
  - <span style="color:#a3be8c">cleanup</span>

<span style="color:#8fa1b3">build_job</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">build</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">make build</span>

<span style="color:#8fa1b3">cleanup_build_job</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">cleanup_build</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">cleanup build when failed</span>
  <span style="color:#8fa1b3">when</span>: <span style="color:#a3be8c">on_failure</span>

<span style="color:#8fa1b3">test_job</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">test</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">make test</span>

<span style="color:#8fa1b3">deploy_job</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">deploy</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">make deploy</span>
  <span style="color:#8fa1b3">when</span>: <span style="color:#a3be8c">manual</span>

<span style="color:#8fa1b3">cleanup_job</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">cleanup</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">cleanup after jobs</span>
  <span style="color:#8fa1b3">when</span>: <span style="color:#a3be8c">always</span>
</code></span></span>

上面的脚本将：

  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关键字可以定义为：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">deploy to production</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">deploy</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">git push production HEAD:master</span>
  <span style="color:#8fa1b3">environment</span>:
    <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">production</span>
</code></span></span>

在上面的示例中，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：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">deploy to production</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">deploy</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">git push production HEAD:master</span>
  <span style="color:#8fa1b3">environment</span>:
    <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">production</span>
</code></span></span>

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。

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">deploy to production</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">deploy</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">git push production HEAD:master</span>
  <span style="color:#8fa1b3">environment</span>:
    <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">production</span>
    <span style="color:#8fa1b3">url</span>: <span style="color:#a3be8c">https://prod.example.com</span>
</code></span></span>

environment:on_stop 

笔记：

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

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

阅读本environment:action节的示例。

environment:action 

在GitLab 8.13中引入。

该action关键字将与on_stop调用以关闭环境的作业一起使用并在其中定义。

举个例子：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">review_app</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">deploy</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make deploy-app</span>
  <span style="color:#8fa1b3">environment</span>:
    <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">review</span>
    <span style="color:#8fa1b3">on_stop</span>: <span style="color:#a3be8c">stop_review_app</span>

<span style="color:#8fa1b3">stop_review_app</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">deploy</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make delete-app</span>
  <span style="color:#8fa1b3">when</span>: <span style="color:#a3be8c">manual</span>
  <span style="color:#8fa1b3">environment</span>:
    <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">review</span>
    <span style="color:#8fa1b3">action</span>: <span style="color:#a3be8c">stop</span>
</code></span></span>

在上面的示例中，我们将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。

例如：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">deploy as review app</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">deploy</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make deploy</span>
  <span style="color:#8fa1b3">environment</span>:
    <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">review/$CI_COMMIT_REF_NAME</span>
    <span style="color:#8fa1b3">url</span>: <span style="color:#a3be8c">https://$CI_ENVIRONMENT_SLUG.example.com/</span>
</code></span></span>

该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文件：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">rspec</span>:
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">test</span>
  <span style="color:#8fa1b3">cache</span>:
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">binaries/*.apk</span>
      - <span style="color:#a3be8c">.config</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">cache</span>:
  <span style="color:#8fa1b3">paths</span>:
    - <span style="color:#a3be8c">my/files</span>

<span style="color:#8fa1b3">rspec</span>:
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">test</span>
  <span style="color:#8fa1b3">cache</span>:
    <span style="color:#8fa1b3">key</span>: <span style="color:#a3be8c">rspec</span>
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">binaries/</span>
</code></span></span>

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

cache:key 

在GitLab Runner v1.0.0中引入。

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

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

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

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

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">cache</span>:
  <span style="color:#8fa1b3">key</span>: <span style="color:#a3be8c">"</span><span style="color:#a3be8c">$CI_COMMIT_REF_SLUG"</span>
  <span style="color:#8fa1b3">paths</span>:
    - <span style="color:#a3be8c">binaries/</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">cache</span>:
  <span style="color:#8fa1b3">key</span>: <span style="color:#a3be8c">"</span><span style="color:#a3be8c">%CI_COMMIT_REF_SLUG%"</span>
  <span style="color:#8fa1b3">paths</span>:
    - <span style="color:#a3be8c">binaries/</span>
</code></span></span>

cache:untracked 

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">rspec</span>:
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">test</span>
  <span style="color:#8fa1b3">cache</span>:
    <span style="color:#8fa1b3">untracked</span>: <span style="color:#bf616a">true</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">rspec</span>:
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">test</span>
  <span style="color:#8fa1b3">cache</span>:
    <span style="color:#8fa1b3">untracked</span>: <span style="color:#bf616a">true</span>
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">binaries/</span>
</code></span></span>

cache:policy 

在GitLab 9.4中引入。

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

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">stages</span>:
  - <span style="color:#a3be8c">setup</span>
  - <span style="color:#a3be8c">test</span>

<span style="color:#8fa1b3">prepare</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">setup</span>
  <span style="color:#8fa1b3">cache</span>:
    <span style="color:#8fa1b3">key</span>: <span style="color:#a3be8c">gems</span>
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">vendor/bundle</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">bundle install --deployment</span>

<span style="color:#8fa1b3">rspec</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">test</span>
  <span style="color:#8fa1b3">cache</span>:
    <span style="color:#8fa1b3">key</span>: <span style="color:#a3be8c">gems</span>
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">vendor/bundle</span>
    <span style="color:#8fa1b3">policy</span>: <span style="color:#a3be8c">pull</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">bundle exec rspec ...</span>
</code></span></span>

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

此外，如果您的作业无条件地重新创建缓存而不参考其先前的内容，则可以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：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">artifacts</span>:
  <span style="color:#8fa1b3">paths</span>:
    - <span style="color:#a3be8c">binaries/</span>
    - <span style="color:#a3be8c">.config</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">build</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make build</span>
  <span style="color:#8fa1b3">dependencies</span>: []
</code></span></span>

您可能希望仅为标记版本创建工件，以避免使用临时构建工件填充构建服务器存储。

仅为标记创建工件（default-job不会创建工件）：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">default-job</span>:
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">mvn test -U</span>
  <span style="color:#8fa1b3">except</span>:
    - <span style="color:#a3be8c">tags</span>

<span style="color:#8fa1b3">release-job</span>:
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">mvn package -U</span>
  <span style="color:#8fa1b3">artifacts</span>:
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">target/*.war</span>
  <span style="color:#8fa1b3">only</span>:
    - <span style="color:#a3be8c">tags</span>
</code></span></span>

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正确命名工件。

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">artifacts</span>:
    <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">"</span><span style="color:#a3be8c">$CI_JOB_NAME"</span>
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">binaries/</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
   <span style="color:#8fa1b3">artifacts</span>:
     <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">"</span><span style="color:#a3be8c">$CI_COMMIT_REF_NAME"</span>
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">binaries/</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">artifacts</span>:
    <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">"</span><span style="color:#a3be8c">$CI_JOB_NAME-$CI_COMMIT_REF_NAME"</span>
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">binaries/</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">artifacts</span>:
    <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">"</span><span style="color:#a3be8c">$CI_JOB_STAGE-$CI_COMMIT_REF_NAME"</span>
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">binaries/</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">artifacts</span>:
    <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">"</span><span style="color:#a3be8c">%CI_JOB_STAGE%-%CI_COMMIT_REF_NAME%"</span>
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">binaries/</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">artifacts</span>:
    <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">"</span><span style="color:#a3be8c">$env:CI_JOB_STAGE-$env:CI_COMMIT_REF_NAME"</span>
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">binaries/</span>
</code></span></span>

artifacts:untracked 

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

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

发送所有Git未跟踪文件：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">artifacts</span>:
  <span style="color:#8fa1b3">untracked</span>: <span style="color:#bf616a">true</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">artifacts</span>:
  <span style="color:#8fa1b3">untracked</span>: <span style="color:#bf616a">true</span>
  <span style="color:#8fa1b3">paths</span>:
    - <span style="color:#a3be8c">binaries/</span>
</code></span></span>

artifacts:when 

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

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

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

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

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">artifacts</span>:
    <span style="color:#8fa1b3">when</span>: <span style="color:#a3be8c">on_failure</span>
</code></span></span>

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周后过期文物：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job</span>:
  <span style="color:#8fa1b3">artifacts</span>:
    <span style="color:#8fa1b3">expire_in</span>: <span style="color:#a3be8c">1 week</span>
</code></span></span>

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由于阶段优先级，作业将从以前的所有作业下载工件：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#a3be8c">build:osx</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">build</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make build:osx</span>
  <span style="color:#8fa1b3">artifacts</span>:
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">binaries/</span>

<span style="color:#a3be8c">build:linux</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">build</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make build:linux</span>
  <span style="color:#8fa1b3">artifacts</span>:
    <span style="color:#8fa1b3">paths</span>:
      - <span style="color:#a3be8c">binaries/</span>

<span style="color:#a3be8c">test:osx</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">test</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make test:osx</span>
  <span style="color:#8fa1b3">dependencies</span>:
    - <span style="color:#a3be8c">build:osx</span>

<span style="color:#a3be8c">test:linux</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">test</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make test:linux</span>
  <span style="color:#8fa1b3">dependencies</span>:
    - <span style="color:#a3be8c">build:linux</span>

<span style="color:#8fa1b3">deploy</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">deploy</span>
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">make deploy</span>
</code></span></span>

当依赖作业失败时 

在GitLab 10.3中引入。

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

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

coverage 

在GitLab 8.17中引入。

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

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

一个简单的例子：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job1</span>:
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">rspec</span>
  <span style="color:#8fa1b3">coverage</span>: <span style="color:#a3be8c">'</span><span style="color:#a3be8c">/Code</span> <span style="color:#a3be8c">coverage:</span> <span style="color:#a3be8c">\d+\.\d+/'</span>
</code></span></span>

retry 

在GitLab 9.5中引入。

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

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

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

一个简单的例子：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">test</span>:
  <span style="color:#8fa1b3">script</span>: <span style="color:#a3be8c">rspec</span>
  <span style="color:#8fa1b3">retry</span>: <span style="color:#a3be8c">2</span>
</code></span></span>

include

起动机

青铜

 

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

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

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#65737e"># Content of https://gitlab.com/awesome-project/raw/master/.before-script-template.yml</span>

<span style="color:#8fa1b3">before_script</span>:
  - <span style="color:#a3be8c">apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs</span>
  - <span style="color:#a3be8c">gem install bundler --no-ri --no-rdoc</span>
  - <span style="color:#a3be8c">bundle install --jobs $(nproc)  "${FLAGS[@]}"</span>
</code></span></span>
<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#65737e"># Content of .gitlab-ci.yml</span>

<span style="color:#8fa1b3">include</span>: <span style="color:#a3be8c">'</span><span style="color:#a3be8c">https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'</span>

<span style="color:#8fa1b3">rspec</span>:
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">bundle exec rspec</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#65737e"># Single string</span>

<span style="color:#8fa1b3">include</span>: <span style="color:#a3be8c">'</span><span style="color:#a3be8c">/templates/.after-script-template.yml'</span>
</code></span></span>
<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#65737e"># Array</span>

<span style="color:#8fa1b3">include</span>:
  - <span style="color:#a3be8c">'</span><span style="color:#a3be8c">https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'</span>
  - <span style="color:#a3be8c">'</span><span style="color:#a3be8c">/templates/.after-script-template.yml'</span>
</code></span></span>

include 支持两种类型的文件：

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

    <span style="color:#eff1f5"><code><span style="color:#65737e"># Within the repository</span>
<span style="color:#8fa1b3">include</span>: <span style="color:#a3be8c">'</span><span style="color:#a3be8c">/templates/.gitlab-ci-template.yml'</span>
</code></span>

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

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

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

    <span style="color:#eff1f5"><code><span style="color:#8fa1b3">include</span>: <span style="color:#a3be8c">'</span><span style="color:#a3be8c">https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml'</span>
</code></span>

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

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

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#65737e"># Content of https://company.com/autodevops-template.yml</span>

<span style="color:#8fa1b3">variables</span>:
  <span style="color:#8fa1b3">POSTGRES_USER</span>: <span style="color:#a3be8c">user</span>
  <span style="color:#8fa1b3">POSTGRES_PASSWORD</span>: <span style="color:#a3be8c">testing_password</span>
  <span style="color:#8fa1b3">POSTGRES_DB</span>: <span style="color:#a3be8c">$CI_ENVIRONMENT_SLUG</span>

<span style="color:#8fa1b3">production</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">production</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">install_dependencies</span>
    - <span style="color:#a3be8c">deploy</span>
  <span style="color:#8fa1b3">environment</span>:
    <span style="color:#8fa1b3">name</span>: <span style="color:#a3be8c">production</span>
    <span style="color:#8fa1b3">url</span>: <span style="color:#a3be8c">https://$CI_PROJECT_PATH_SLUG.$AUTO_DEVOPS_DOMAIN</span>
  <span style="color:#8fa1b3">only</span>:
    - <span style="color:#a3be8c">master</span>
</code></span></span>
<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#65737e"># Content of .gitlab-ci.yml</span>

<span style="color:#8fa1b3">include</span>: <span style="color:#a3be8c">'</span><span style="color:#a3be8c">https://company.com/autodevops-template.yml'</span>

<span style="color:#8fa1b3">image</span>: <span style="color:#a3be8c">alpine:latest</span>

<span style="color:#8fa1b3">variables</span>:
  <span style="color:#8fa1b3">POSTGRES_USER</span>: <span style="color:#a3be8c">root</span>
  <span style="color:#8fa1b3">POSTGRES_PASSWORD</span>: <span style="color:#a3be8c">secure_password</span>

<span style="color:#8fa1b3">stages</span>:
  - <span style="color:#a3be8c">build</span>
  - <span style="color:#a3be8c">test</span>
  - <span style="color:#a3be8c">production</span>

<span style="color:#8fa1b3">production</span>:
  <span style="color:#8fa1b3">environment</span>:
    <span style="color:#8fa1b3">url</span>: <span style="color:#a3be8c">https://domain.com</span>
</code></span></span>

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

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

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#65737e"># Content of https://company.com/autodevops-template.yml</span>

<span style="color:#8fa1b3">production</span>:
  <span style="color:#8fa1b3">stage</span>: <span style="color:#a3be8c">production</span>
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">install_dependencies</span>
    - <span style="color:#a3be8c">deploy</span>
</code></span></span>
<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#65737e"># Content of .gitlab-ci.yml</span>

<span style="color:#8fa1b3">include</span>: <span style="color:#a3be8c">'</span><span style="color:#a3be8c">https://company.com/autodevops-template.yml'</span>

<span style="color:#8fa1b3">stages</span>:
  - <span style="color:#a3be8c">production</span>

<span style="color:#8fa1b3">production</span>:
  <span style="color:#8fa1b3">script</span>:
    - <span style="color:#a3be8c">install_depedencies</span>
    - <span style="color:#a3be8c">deploy</span>
    - <span style="color:#a3be8c">notify_owner</span>
</code></span></span>

在这种情况下，如果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存储库中，用于存储非敏感项目配置，例如：

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">variables</span>:
  <span style="color:#8fa1b3">DATABASE_URL</span>: <span style="color:#a3be8c">"</span><span style="color:#a3be8c">postgres://postgres@postgres/my_database"</span>
</code></span></span>

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

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">job_name</span>:
  <span style="color:#8fa1b3">variables</span>: {}
</code></span></span>

除了用户定义的变量之外，还有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是最慢的选择。它从头开始为每个作业克隆存储库，确保项目工作区始终保持原始状态。

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">variables</span>:
  <span style="color:#8fa1b3">GIT_STRATEGY</span>: <span style="color:#a3be8c">clone</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">variables</span>:
  <span style="color:#8fa1b3">GIT_STRATEGY</span>: <span style="color:#a3be8c">fetch</span>
</code></span></span>

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

<span style="color:#333333"><span style="color:#eff1f5"><code><span style="color:#8fa1b3">variables</span>:
  <span style="color:#8fa1b3">GIT_STRATEGY</span>: <span style="color:#a3be8c">none</span></code></span></span>

 

 

小楼看风云
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
gitlab-ci-validate:检查您的 .gitlab-ci.yml 文件是否有效
05-31
安装： yarn global add gitlab-ci-validatenpm i -g gitlab-ci-validate用法： # It will try to find if .gitlab-ci.yml is present on the current folder if no file path is provided$ gitlab-ci-validate ...
Gitlab部署CI并使用.gitlab-ci.yml配置您的作业(中文翻译)
热门推荐
琪琪的博客
04-12 5万+
本文档描述了.gitlab-ci.ymlGitLab Runner用于管理项目作业的文件的用法。 如果您想快速介绍GitLab CI，请按照我们的 快速入门指南。 .gitlab-ci.yml  从版本7.12，GitLab CI使用YAML 文件（.gitlab-ci.yml）进行项目配置。它放置在存储库的根目录中，并包含如何构建项目的定义。 YAML文件定义了一组具
gitlab--基础--5.4--CICD--variables
zhou920786312的博客
08-23 3231
标识该job是在CI环境中执行。
.gitlab-ci.yml文件参数配置和使用
最新发布
mo_sss的博客
02-05 1713
每个人都有惰性，但不断学习是好好生活的根本，共勉！官网参考文档：https://docs.gitlab.com/ee/ci/index.html#the-gitlab-ciyml-file
.gitlab-ci.yml说明
mmgithub123的博客
05-07 7410
Gitlab官方文档：https://docs.gitlab.com/ee/ci/yaml/README.html https://docs.gitlab.com/ee/ci/yaml/gitlab_ci_yaml.html https://docs.gitlab.com/ee/ci/docker/using_docker_images.html GitLab CI/CD 是一个内置在GitL...
GitLab CI流水线配置文件.gitlab-ci.yml详解（三）
格物致知
07-31 1940
GitLab CI流水线配置文件.gitlab-ci.yml详解 … contents:: 目录 本文讲解在 :ref:GitLab的汉化与CI持续集成gitlab-runner的配置 <configure_gitlab_i18n_and_create_gitlab_ci_with_gitlab_runner> 的基础上，对GitLab CI流水线配置文件 .gitlab-ci.yml 进行详细的介绍。 文章目录GitLab CI流水线配置文件.gitlab-ci.yml详解1. 实验环境2.
gitlab-ci.yaml 配置文件详解
JineD的博客
09-22 1万+
通过 .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)来管理项目配置。该文件存放于项目仓库的根目录，它定义该项目如何构建。 开始构建之前YAM
【笔记】gitlab-ci 文件增加判断语句的方式
点滴
08-18 2444
环境比较多，根据分支名判断部署的位置，减少编写代码量 注意点： 判断语句中变量不要带引号"" 判断语句中 中括号 两边内部要有空格； build_test: stage: deploy script: - echo "$CI_COMMIT_REF_NAME" - | if [ $CI_COMMIT_REF_NAME == "dev" ]; then node -v else echo "123" fi
.gitlab-ci.yml 配置文件详解
u014265398的博客
04-21 2万+
值 是否必须 描述 script 必须 定义由Runner执行的shell脚本或命令 extends 非必须 定义此作业将继承的配置条目 image 非必须 需要使用的docker镜像，请查阅该文档 services 非必须 定义所需的docker服务，请查阅该文档 stage 非必须 定义一个工作场景阶段，默认是test type 非必须 stage的别名,不赞成使用 variabl...
gitlab-ci-lint:gitlab-ci cli到lint .gitlab-ci.yml文件
04-29
gitlab-ci cli到lint .gitlab-ci.yml文件 用法 安装 npm install -g gitlab-ci-lint 命令行界面 Usage: gitlab-ci-lint [options] Options: -h, --help output usage information -V, --version output the ...
.gitlab-ci.yml Model
04-24
GitLab Runner 自动部署发布项目的 .gitlab-ci.yml 文件模板
gitlab-ci-yml：我的项目使用的GitLab CI配置文件的集合
02-08
每个dockerfile都有一个简单的.gitlab-ci.yml文件，该文件使用我.gitlab-ci.yml映像之一。 该定义所引用的资源不包括在该项目中。 您可以从复制.gitlab-cy.yml ，然后替换相关位。 stages : - build build : ...
gitlab-ci-yml:可重复使用的Giltlab管道
03-26
.gitlab-ci.yml :sparkles: :sparkles: :sparkles: :sparkles: :sparkles: :sparkles: :sparkles: :sparkles: 用法 在.gitlab-ci.yml ： --- include : - project : SocialGouv/gitlab-ci-yml file : /base_...
GitLab CI 从入门到实践
奇舞周刊
02-16 1207
一、Gitlab CI 是什么？现代持续的软件开发导致了开发者需要持续的build, test 和 deploy 重复的代码更改，这些重复的过程非常的繁琐，但是对保证代码持续更新迭代来说又...
.gitlab-ci.yml参数学习
mtsunbw的博客
12-30 4204
gitlab-runner语法 .gitlab-ci.yml .gitlab-ci.yml 用来配置 CI 用你的项目中做哪些操作，这个文件位于仓库的根目录。 当有新内容 push 到仓库，或者有代码合并后， GitLab 会查找是否有 .gitlab-ci.yml 文件，如果文件存在， Runners 将会根据该文件的内容开始 build 本次 commit 。 .gitlab-ci.yml 使用 YAML 语法， 你需要格外注意缩进格式，要用空格来缩进，不能用 tabs 来缩进。 Stages
GitLab中的.gitlab-ci.yml文件
北辰
11-27 1473
GitLab中某一个项目下的.gitlab-ci.yml文件主要是用于告诉执行器(GitLab Runner实例）需要做哪些事情。
持续集成gitlab-ci.yml配置文档基础
cxzhq2002的杂记
12-20 299
管道是持续集成、交付和部署的顶级组件是一组分阶段（批处理）执行的工作。同一个阶段中的所有工作都是并行执行的（如果有足够的并发Runners），如果它们全部成功，管道就进入下一个阶段。如果其中一个jobs失败，则下一个阶段不（通常）执行。您可以访问项目的Pipeline选项卡中的管道页面。在下图中，您可以看到管道由4个阶段组成（build(构建) , test(测试) , staging(分级) , production(生产)），每个阶段都有一个或多个工作。
手把手教学编写gitlab-ci.yml文件以及应用（最简单易懂实践）
qq_27759825的博客
05-10 1万+
编写gitlab-ci.yml文件以及应用
gitlab-ci.yml
08-11
gitlab-ci.yml是GitLab中用于配置持续集成/持续部署（CI/CD）流程的文件。它使用YAML语法来定义一系列的作业（jobs）和阶段（stages），并指定每个作业在何时运行以及如何运行。 在gitlab-ci.yml文件中，你可以定义多个阶段，每个阶段可以包含一个或多个作业。作业是CI/CD流程中的最小执行单元，它可以是构建、测试、部署等任务。 以下是一个简单的gitlab-ci.yml示例： ```yaml stages: - build - test - deploy build_job: stage: build script: - echo "Building..." test_job: stage: test script: - echo "Running tests..." deploy_job: stage: deploy script: - echo "Deploying..." ``` 在上面的示例中，我们定义了三个阶段：build、test和deploy。每个阶段只有一个作业，分别是build_job、test_job和deploy_job。每个作业都有一个script字段，用于指定作业需要执行的命令。 当你提交代码到GitLab仓库时，GitLab将根据gitlab-ci.yml文件中的配置来运行相应的作业，以实现自动化的构建、测试和部署流程。 请注意，gitlab-ci.yml文件的具体配置取决于你的项目需求和CI/CD流程的复杂度，上述示例只是一个简单的演示。你可以根据你的项目需要来自定义配置。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值