原文

GitLab CI/CD管道配置参考

GitLab CI/CD管道在每个项目中使用名为 .gitlab-ci.yml 的YAML文件进行配置。
.gitlab-ci.yml 文件定义管道的结构和顺序，并确定：

• 使用GitLab Runner执行什么。
• 遇到具体情况时要做什么决定。例如，当进程成功或失败时。

本主题涵盖CI/CD管道配置。有关其他CI/CD配置信息，请参见：

• GitLab CI/CD变量，用于配置管道运行的环境。
• GitLab Runner高级配置，用于配置GitLab Runner。

我们有配置管道的完整示例：

• 要快速介绍GitLab CI/CD，请遵循我们的快速入门指南。
• 有关示例的集合，请参见GitLab CI/CD示例。
• 要查看企业中使用的大型.gitlab-ci.yml文件，请参阅GitLab的.gitlab-ci.yml文件。

有关GitLab CI/CD的其他信息：
观看CI/CD轻松配置视频。

如果您有GitLab从中提取的镜像存储库，则可能需要启用管道触发。去你的项目，Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates

介绍

管道配置从jobs开始。jobs是.gitlab-ci.yml文件中最基本的元素。
jobs如下：

• 用约束来定义，说明在什么条件下应该执行这些约束。
• 具有任意名称的顶级元素，并且必须至少包含脚本子句.
• 不限于可以定义多少。

举例：

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

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

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

jobs 由 runner 接收到并且在 runner 的环境中执行，重要的是每个任务都是独立运行的。

验证 .gitlab-ci.yml

GitLab CI/CD 的每一个实例都有一个名为 Lint 的嵌入式调试工具。它验证了.gitlab-ci.yml文件的内容。你可以在你项目的命名空间下的页面 ci/lint 找到 Lint，举例，https://gitlab.example.com/gitlab-org/project-123/-/ci/lint.

不可用的 jobs 名称

每个jobs必须有一个唯一的名称，但是有几个保留的关键字不能用作jobs名称：

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

使用保留关键字

如果在使用特定值(例如，true或false)时出现验证错误，请尝试：

• 声明它
• 把它们换到另一种形式。例如 /bin/true。

配置参数

一个 job 被定义为定义job行为的参数列表。

下表列出了 jobs 的可用参数：

关键词	描述
script	被 runner 执行的shell 脚本
after_script	重写一套在 job 后执行的命令。
allow_failure	允许 job 失败，失败的 job 不会导致 commit 状态改变
artifacts	成功后要附加到job的文件和目录列表。仍然可用的：artifacts:paths, artifacts:exclude, artifacts:expose_as, artifacts:name, artifacts:untracked, artifacts:when, artifacts:expire_in, and artifacts:reports.
before_script	重写一套在 job 前执行的命令。
cache	应在后续运行期间缓存的文件列表。也可用：cache:paths, cache:key, cache:untracked, cache:when, and cache:policy.
coverage	给定job的代码覆盖率设置。
dependencies	定义了该job依赖哪一个job，如果设置该项，可以通过artifacts设置
except	限制未创建作业的时间。也可用：except:refs, except:kubernetes, except:variables, and except:changes.
extends	此作业继承的配置项。
image	使用 docker 镜像，也可用：image:name and image:entrypoint.
include	允许此作业包含外部YAML文件。也可用：include:local, include:file, include:template, and include:remote.
interruptible	定义在较新的运行使job变得冗余时是否可以取消job。
only	限制 job 创建的时间，也可用：only:refs, only:kubernetes, only:variables, and only:changes.
pages	上传与 gitlab pages 一起使用的结果
parallel	一个 job 的多少个实例可以同时运行
release	指示运行程序生成一个发布对象。
resource_group	限制 job 并发
retry	在失败的情况下，一个job可以自动重试几次。
rules	用于评估和确定作业的选定属性的条件列表，以及是否创建了该属性。不得only/except一起使用。
services	使用 Docker services images，也可用：services:name, services:alias, services:entrypoint, and services:command.
stage	定义 job 阶段（默认：test）
timeout	定义优先于项目范围设置的自定义作业级超时。
trigger	定义一个向下流动的管道触发器
variables	在 job 级别定义 job 变量
when	什么时候运行 job，也可用：when:manual and when:delayed.

全局参数

某些参数必须在全局级别上定义，影响到正在执行中的所有作业。

全局默认

某些参数可以全局设置为所有作业的默认参数，使用default: keyword，然后，job 特定的配置可以重写默认参数。
以下 job 参数可以在默认情况下default : block
The following job parameters can be defined inside a default: block:

• image
• services
• before_script
• after_script
• tags
• cache
• artifacts
• retry
• timeout
• interruptible

在下面的示例中，ruby:2.5 镜像被设置为除 rspec 2.6 job 之外的所有 jobs 的默认值，ruby:2.6 job 使用 ruby:2.6 镜像：

default:
  image: ruby:2.5

rspec:
  script: bundle exec rspec

rspec 2.6:
  image: ruby:2.6
  script: bundle exec rspec

inherit

Introduced in GitLab 12.9.

您可以禁用对全局定义的默认值和变量的继承。

若要启用或禁用所有的继承，变量或默认参数，请使用以下格式：
default: true or default: false
variables: true or variables: false

若要仅继承 变量或默认参数，请指定要继承的内容。没有列出的任何东西都不会被继承。使用下列格式之一：

inherit:
  default: [parameter1, parameter2]
  variables: [VARIABLE1, VARIABLE2]

Or:

inherit:
  default:
    - parameter1
    - parameter2
  variables:
    - VARIABLE1
    - VARIABLE2

在下面的例子中：
rubocop：

• 继承: Nothing.

rspec：

• 继承：默认的image 和 WEBHOOK_URL 变量
• 非继承：默认的 before_script 和 DOMAIN 变量

capybara：

• 继承：默认的 before_script 和 image
• 非继承：默认的 DOMAIN 和 WEBHOOK_URL 变量

karma：

• 继承：默认的 image 和 before_script，和 DOMAIN 变量
• 非继承：WEBHOOK_URL 变量

default:
  image: 'ruby:2.4'
  before_script:
    - echo Hello World

variables:
  DOMAIN: example.com
  WEBHOOK_URL: https://my-webhook.example.com

rubocop:
  inherit:
    default: false
    variables: false
  script: bundle exec rubocop

rspec:
  inherit:
    default: [image]
    variables: [WEBHOOK_URL]
  script: bundle exec rspec

capybara:
  inherit:
    variables: false
  script: bundle exec capybara

karma:
  inherit:
    default: true
    variables: [DOMAIN]
  script: karma

stages

stages 用于定义包含 job 的阶段，并在全局范围内为管道定义。

stages 要求允许有灵活的 stage 多级管道，每个 stages 的元素定义了执行 job 的顺序：

1. 相同 stage 的 job 是平级执行的
2. 下一 stage 的 job 在上一 stage 的 job 执行成功后执行

让我们考虑下面的示例，它定义了三个阶段：

stages:
  - build
  - test
  - deploy

1. 首先，所有的 build jobs 都并行执行。
2. 如果所有的的 build jobs 都执行成功，test jobs 开始并行执行
3. 如果所有的的 test jobs 都执行成功，deploy jobs 开始并行执行
4. 如果所有的的 deploy jobs 都执行成功，这次提交会被标记为 passed
5. 如果以前的任何 jobs 失败，则将提交标记为“failed”，并且不会执行进一步阶段的 jobs。

还有两种边缘情况值得一提：

1. 如果没有在 .gitlab-ci.yml 定义 stages，默认情况下，允许 build test deploy 被用在 job’s stage
2. 如果一个 job 没有明确定义一个 stages，那么将被分配到 test stages。