概念

要使用 GitLab CI/CD，您需要：

托管在 Git 存储库中的应用程序代码。
.gitlab-ci.yml在存储库的根目录中调用的文件，其中包含 CI/CD 配置。

在.gitlab-ci.yml文件中，您可以定义：

您要运行的脚本。
您要包含的其他配置文件和模板。
依赖项和缓存。
您要按顺序运行的命令和要并行运行的命令。
将应用程序部署到的位置。
无论您是想自动运行脚本还是手动触发其中的任何一个。

脚本被分组到作业中，作业作为更大管道的一部分运行。您可以将多个独立作业分组到按定义顺序运行的阶段。CI/CD 配置至少需要一项未隐藏的作业。

您应该按照适合您的应用程序并符合您希望执行的测试的顺序组织您的工作。为了可视化该过程，假设您添加到作业的脚本与您在计算机上运行的 CLI 命令相同。

当您将.gitlab-ci.yml文件添加到存储库时，GitLab 会检测到它，并且名为GitLab Runner的应用程序会运行作业中定义的脚本。

一个.gitlab-ci.yml文件可能包含：

stages:
  - build
  - test

build-code-job:
  stage: build
  script:
    - echo "Check the ruby version, then build some Ruby project files:"
    - ruby -v
    - rake

test-code-job1:
  stage: test
  script:
    - echo "If the files are built successfully, test some files with one command:"
    - rake test1

test-code-job2:
  stage: test
  script:
    - echo "If the files are built successfully, test other files with a different command:"
    - rake test2

在此示例build-code-job中，阶段中的作业build首先运行。它输出作业正在使用的 Ruby 版本，然后运行rake以构建项目文件。如果此作业成功完成，test-code-job该阶段中的两个作业将test并行启动并对文件运行测试。

示例中的完整管道由三个作业组成，分为两个阶段， build并且test. 每次将更改推送到项目中的任何分支时，管道都会运行。

GitLab CI/CD 不仅执行作业，还向您展示执行期间发生的情况，就像您在终端中看到的一样：

job_running_v13_10

您为您的应用程序创建策略，GitLab 根据您定义的内容运行管道。GitLab 也会显示您的管道状态： pipeline_status

如果出现任何问题，您可以回滚更改： rollback

关键词

配置管道行为的全局关键字：

关键词	描述
default	工作关键字的自定义默认值。
include	从其他 YAML 文件导入配置。
stages	流水线阶段的名称和顺序。
variables	为管道中的所有作业定义 CI/CD 变量。
workflow	控制运行什么类型的管道。

使用作业关键字配置的作业：

关键词	描述
after_script	覆盖作业后执行的一组命令。
allow_failure	允许作业失败。失败的作业不会导致管道失败。
artifacts	成功后附加到作业的文件和目录列表。
before_script	覆盖在作业之前执行的一组命令。
cache	应在后续运行之间缓存的文件列表。
coverage	给定作业的代码覆盖率设置。
dast_configuration	在作业级别使用 DAST 配置文件中的配置。
dependencies	通过提供要从中获取工件的作业列表来限制将哪些工件传递给特定作业。
environment	作业部署到的环境的名称。
except	控制何时不创建作业。
extends	此作业继承的配置条目。
image	使用 Docker 镜像。
inherit	选择所有作业继承的全局默认值。
interruptible	定义一个作业是否可以在被较新的运行冗余时取消。
needs	在阶段排序之前执行作业。
only	控制何时创建工作。
pages	上传作业结果以与 GitLab 页面一起使用。
parallel	应并行运行多少个作业实例。
release	指示运行器生成释放对象。
resource_group	限制作业并发。
retry	发生故障时可以自动重试作业的时间和次数。
rules	用于评估和确定作业的选定属性以及是否已创建的条件列表。
script	由运行程序执行的 Shell 脚本。
secrets	CI/CD 是工作需要的秘密。
services	使用 Docker 服务镜像。
stage	定义作业阶段。
tags	用于选择跑步者的标签列表。
timeout	定义优先于项目范围设置的自定义作业级超时。
trigger	定义下游管道触发器。
variables	在工作级别定义工作变量。
when	何时运行作业。

全局关键字

某些关键字未在作业中定义。这些关键字控制管道行为或导入额外的管道配置。

1. default

您可以为某些关键字设置全局默认值。未定义一个或多个列出的关键字的作业使用该default部分中定义的值。

示例default：

default:
  image: ruby:3.0

rspec:
  script: bundle exec rspec

rspec 2.7:
  image: ruby:2.7
  script: bundle exec rspec

在此示例中，ruby:3.0是管道中所有作业的默认image值。该rspec 2.7作业不使用默认值，因为它使用特定于作业的image部分覆盖默认值：

附加细节：

创建管道时，每个默认值都会复制到所有未定义该关键字的作业。
如果作业已经配置了其中一个关键字，则作业中的配置优先，不会被默认值替换。
使用 .控制作业中默认关键字的继承inherit:default。

2. include

用于include在 CI/CD 配置中包含外部 YAML 文件。您可以将一个长.gitlab-ci.yml文件拆分为多个文件以增加可读性，或减少在多个位置重复相同的配置。

您还可以将模板文件存储在中央存储库中并将它们包含在项目中。

这些include文件是：

与.gitlab-ci.yml文件中的内容合并。
.gitlab-ci.yml无论include关键字的位置如何，始终先评估然后与文件的内容合并。

2.1 include:local

用于include:local包含与文件位于同一存储库中的.gitlab-ci.yml文件。使用include:local而不是符号链接。

相对于根目录 ( /) 的完整路径：

YAML 文件必须具有扩展名.yml或.yaml.
您可以在文件路径中使用*和**通配符。
您可以使用某些 CI/CD 变量。

示例include:local：

include:
  - local: '/templates/.gitlab-ci-template.yml'

您还可以使用更短的语法来定义路径：

include: '.gitlab-ci-production.yml'

附加细节：

.gitlab-ci.yml文件和本地文件必须在同一个分支上。
您不能通过 Git 子模块路径包含本地文件。
所有嵌套包含都在同一个项目的范围内执行，因此您可以使用本地、项目、远程或模板包含。

2.2 include:file

要在同一个 GitLab 实例上包含来自另一个私有项目的文件，请使用include:file. 您可以仅include:file结合使用include:project。

相对于根目录 ( /) 的完整路径：

YAML 文件必须具有扩展名.yml或.yaml.
您可以使用某些 CI/CD 变量。

示例include:file：

include:
  - project: 'my-group/my-project'
    file: '/templates/.gitlab-ci-template.yml'

您还可以指定一个ref. 如果不指定值，则 ref 默认为HEAD项目的：

include:
  - project: 'my-group/my-project'
    ref: main
    file: '/templates/.gitlab-ci-template.yml'

  - project: 'my-group/my-project'
    ref: v1.0.0  # Git Tag
    file: '/templates/.gitlab-ci-template.yml'

  - project: 'my-group/my-project'
    ref: 787123b47f14b552955ca2786bc9542ae66fee5b  # Git SHA
    file: '/templates/.gitlab-ci-template.yml'

您可以包含来自同一项目的多个文件：

include:
  - project: 'my-group/my-project'
    ref: main
    file:
      - '/templates/.builds.yml'
      - '/templates/.tests.yml'

附加细节：

所有嵌套包含都在目标项目的范围内执行。您可以使用local（相对于目标项目）、、、project或remote包含template。
当管道启动时，.gitlab-ci.yml会评估所有方法包含的文件配置。配置是及时的快照，并保留在数据库中。.gitlab-ci.yml在下一个管道开始之前，GitLab 不会反映对引用文件配置的任何更改。
当您包含来自另一个私有项目的 YAML 文件时，运行管道的用户必须是这两个项目的成员并且具有运行管道的适当权限。如果not found or access denied用户无权访问任何包含的文件，则可能会显示错误。

2.3 include:remote

与完整 URL 一起使用include:remote以包含来自不同位置的文件。

HTTP/HTTPSGET请求可访问的公共 URL：

不支持使用远程 URL 进行身份验证。
YAML 文件必须具有扩展名.yml或.yaml.
您可以使用某些 CI/CD 变量。

示例include:remote：

include:
  - remote: 'https://gitlab.com/example-project/-/raw/main/.gitlab-ci.yml'

附加细节：

所有嵌套包含作为公共用户在没有上下文的情况下执行，因此您只能包含公共项目或模板。
包含远程 CI/CD 配置文件时要小心。当外部 CI/CD 配置文件更改时，不会触发管道或通知。从安全角度来看，这类似于拉取第三方依赖。

2.4 include:template

用于include:template包含.gitlab-ci.yml模板。

一个CI/CD 模板：

模板存储在lib/gitlab/ci/templates. 并非所有模板都设计为与一起使用include:template，因此在使用模板之前请检查模板注释。
您可以使用某些 CI/CD 变量。

示例include:template：

# File sourced from the GitLab template collection
include:
  - template: Auto-DevOps.gitlab-ci.yml

多个include:template文件：

include:
  - template: Android-Fastlane.gitlab-ci.yml
  - template: Auto-DevOps.gitlab-ci.yml

附加细节：

所有嵌套的包含仅在用户许可的情况下执行，因此可以使用project、、remote或template包含。

3. stages

用于stages定义包含作业组的阶段。在作业中使用stage 以将作业配置为在特定阶段运行。

如果stages未在.gitlab-ci.yml文件中定义，则默认管道阶段为：

.pre
build
test
deploy
.post

中项目的顺序stages定义了作业的执行顺序：

同一阶段的作业并行运行。
下一阶段的作业在上一阶段的作业成功完成后运行。

如果管道仅包含.preor.post阶段中的作业，则它不会运行。在不同的阶段必须至少有一项其他工作。.pre和.post阶段可用于所需的管道配置，以定义必须在项目管道作业之前或之后运行的合规作业。

示例stages：

stages:
  - build
  - test
  - deploy

4. workflow

用于workflow控制管道行为。

4.1 workflow:rules

rulesin 关键字workflow类似于rulesjobs 中的定义，但控制是否创建整个管道。

当没有规则评估为真时，管道不会运行。

示例workflow:rules：

workflow:
  rules:
    - if: $CI_COMMIT_TITLE =~ /-draft$/
      when: never
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

在此示例中，如果提交标题（提交消息的第一行）没有以以下方式结束-draft 并且管道用于以下任一情况，则管道将运行：

合并请求默认分支。

4.2 workflow:rules:variables

您可以使用variablesinworkflow:rules为特定管道条件定义变量。

当条件匹配时，变量被创建并且可以被管道中的所有作业使用。如果变量已在全局级别定义，则该workflow 变量优先并覆盖全局变量。

名称只能使用数字、字母和下划线 ( _)。
该值必须是字符串。

示例workflow:rules:variables：

variables:
  DEPLOY_VARIABLE: "default-deploy"

workflow:
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        DEPLOY_VARIABLE: "deploy-production"  # Override globally-defined DEPLOY_VARIABLE
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # Define a new variable.
    - when: always                            # Run the pipeline in other cases

job1:
  variables:
    DEPLOY_VARIABLE: "job1-default-deploy"
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:                                   # Override DEPLOY_VARIABLE defined
        DEPLOY_VARIABLE: "job1-deploy-production"  # at the job level.
    - when: on_success                             # Run the job in other cases
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"

job2:
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"

当分支是默认分支时：

job1DEPLOY_VARIABLE是job1-deploy-production.
job2DEPLOY_VARIABLE是deploy-production.

当分支是feature：

job1DEPLOY_VARIABLE是job1-default-deploy，并且IS_A_FEATURE是true。
job2DEPLOY_VARIABLE是default-deploy，并且IS_A_FEATURE是true。

当分支是别的东西时：

job1DEPLOY_VARIABLE是job1-default-deploy.
job2DEPLOY_VARIABLE是default-deploy.

工作关键词

1. after_script

用于after_script定义在每个作业之后运行的命令数组，包括失败的作业。

示例after_script：

job:
  script:
    - echo "An example script section."
  after_script:
    - echo "Execute this command after the `script` section completes."

2. allow_failure

用于allow_failure确定当作业失败时管道是否应继续运行。

要让管道继续运行后续作业，请使用allow_failure: true.
要停止管道运行后续作业，请使用allow_failure: false.

当允许作业失败 ( allow_failure: true) 时，橙色警告 ( ) 表示作业失败。但是，管道是成功的，并且关联的提交被标记为通过，没有任何警告。

在以下情况下会显示相同的警告：

阶段中的所有其他作业均成功。
管道中的所有其他作业均成功。

默认值为allow_failure：

true对于手工作业。
false对于使用when: manualinside的作业rules。
false在所有其他情况下。

示例allow_failure：

job1:
  stage: test
  script:
    - execute_script_1

job2:
  stage: test
  script:
    - execute_script_2
  allow_failure: true

job3:
  stage: deploy
  script:
    - deploy_to_staging
  environment: staging

在此示例中，job1并job2并行运行：

如果job1失败，deploy阶段中的作业将不会启动。如果job2失败，deploy阶段中的作业仍然可以启动。

2.1 allow_failure:exit_codes

用于allow_failure:exit_codes控制何时允许作业失败。该作业适用allow_failure: true于任何列出的退出代码，而allow_failure: false 则适用于任何其他退出代码。

test_job_1:
  script:
    - echo "Run a script that results in exit code 1. This job fails."
    - exit 1
  allow_failure:
    exit_codes: 137

test_job_2:
  script:
    - echo "Run a script that results in exit code 137. This job is allowed to fail."
    - exit 137
  allow_failure:
    exit_codes:
      - 137
      - 255

3、artifacts

用于artifacts指定要保存为作业工件的文件。作业工件是作业成功、失败或总是附加到作业的文件和目录列表。

作业完成后，工件将发送到 GitLab。如果大小小于最大工件大小，则可以在 GitLab UI 中下载它们。

默认情况下，后期阶段的作业会自动下载早期阶段作业创建的所有工件。您可以使用 dependencies.

使用needs关键字时，作业只能从needs配置中定义的作业下载工件。

默认情况下，仅收集成功作业的作业工件，并在缓存后恢复工件。

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

3.1 artifacts:paths

路径是相对于项目目录 ( $CI_PROJECT_DIR) 的，不能直接链接到项目目录之外。

示例artifacts:paths：

job:
  artifacts:
    paths:
      - binaries/
      - .config

.config此示例使用目录中的所有文件创建一个工件binaries。

3.2 artifacts:exclude

用于artifacts:exclude防止将文件添加到工件存档中。

示例artifacts:exclude：

artifacts:
  paths:
    - binaries/
  exclude:
    - binaries/**/*.o

此示例将所有文件存储在中binaries/，但不*.o存储位于的子目录中的文件binaries/。

3.3 artifacts:expire_in

用于expire_in指定作业工件在过期和被删除之前存储多长时间。

示例artifacts:expire_in：

job:
  artifacts:
    expire_in: 1 week

3.4 artifacts:expose_as

使用artifacts:expose_as关键字在合并请求 UI 中公开作业工件。

示例artifacts:expose_as：

test:
  script: ["echo 'test' > file.txt"]
  artifacts:
    expose_as: 'artifact 1'
    paths: ['file.txt']

3.5 artifacts:name

使用artifacts:name关键字来定义创建的工件存档的名称。您可以为每个档案指定一个唯一的名称。

如果未定义，则默认名称为artifacts，下载时将变为artifacts.zip。

3.6 artifacts:public

于artifacts:public确定作业工件是否应公开可用。

什么时候artifacts:public是true（默认），公共管道中的工件可供匿名用户和来宾用户下载。

要拒绝匿名用户和来宾用户对公共管道中的工件的读取访问权限，请设置artifacts:public为false：

示例artifacts:public：

job:
  artifacts:
    public: false

3.7 artifacts:reports

用于artifacts:reports收集作业中包含的模板生成的工件。

示例artifacts:reports：

rspec:
  stage: test
  script:
    - bundle install
    - rspec --format RspecJunitFormatter --out rspec.xml
  artifacts:
    reports:
      junit: rspec.xml

3.8 artifacts:untracked

用于artifacts:untracked将所有 Git 未跟踪文件添加为工件（连同定义在中的路径artifacts:paths）。artifacts:untracked忽略存储库中的配置.gitignore，因此包含匹配的工件.gitignore。

示例artifacts:untracked：

保存所有 Git 未跟踪的文件：

job:
  artifacts:
    untracked: true

3.9 artifacts:when

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

示例artifacts:when：

job:
  artifacts:
    when: on_failure

4. before_script

用于定义应在每个作业的命令之前但在工件恢复之后before_script运行的命令数组。script

示例before_script：

job:
  before_script:
    - echo "Execute this command before any 'script:' commands."
  script:
    - echo "This command executes after the job's 'before_script' commands."

5. cache

用于cache指定要在作业之间缓存的文件和目录列表。您只能使用本地工作副本中的路径。

缓存在管道和作业之间共享。缓存在工件之前恢复。

5.1 cache:paths

使用cache:paths关键字选择要缓存的文件或目录。

示例cache:paths：

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

rspec:
  script:
    - echo "This job uses a cache."
  cache:
    key: binaries-cache
    paths:
      - binaries/*.apk
      - .config

5.2 cache:key

使用cache:key关键字给每个缓存一个唯一的标识键。所有使用相同缓存键的作业都使用相同的缓存，包括在不同的管道中。

如果未设置，则默认键为default。所有带有cache关键字但不cache:key共享default缓存的作业。

必须与一起使用cache: path，否则不会缓存任何内容。

示例cache:key：

cache-job:
  script:
    - echo "This job uses a cache."
  cache:
    key: binaries-cache-$CI_COMMIT_REF_SLUG
    paths:
      - binaries/

5.3 cache:key:files

当一个或两个特定文件更改时，使用cache:key:files关键字生成新密钥。cache:key:files允许您重用一些缓存，并减少重建它们的频率，从而加快后续管道运行。示例cache:key:files：

cache-job:
  script:
    - echo "This job uses a cache."
  cache:
    key:
      files:
        - Gemfile.lock
        - package.json
    paths:
      - vendor/ruby
      - node_modules

此示例为 Ruby 和 Node.js 依赖项创建缓存。Gemfile.lock缓存与和package.json文件的当前版本相关联。当其中一个文件发生更改时，将计算一个新的缓存键并创建一个新的缓存。任何将来运行的作业都使用相同的缓存Gemfile.lock并package.json使用cache:key:files 新的缓存，而不是重建依赖项。

5.4 cache:key:prefix

用于cache:key:prefix将前缀与为计算的 SHA 组合cache:key:files。

示例cache:key:prefix：

rspec:
  script:
    - echo "This rspec job uses a cache."
  cache:
    key:
      files:
        - Gemfile.lock
      prefix: $CI_JOB_NAME
    paths:
      - vendor/ruby

例如，添加prefixof$CI_JOB_NAME会使键看起来像rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5。如果分支发生更改Gemfile.lock，则该分支具有新的 SHA 校验和cache:key:files。生成一个新的缓存键，并为该键创建一个新的缓存。如果Gemfile.lock 未找到，则将前缀添加到default，因此示例中的键为rspec-default。

5.5 cache:untracked

用于untracked: true缓存 Git 存储库中未跟踪的所有文件：

示例cache:untracked：

rspec:
  script: test
  cache:
    untracked: true

5.6 cache:when

用于cache:when根据作业的状态定义何时保存缓存。

必须与一起使用cache: path，否则不会缓存任何内容。

示例cache:when：

rspec:
  script: rspec
  cache:
    paths:
      - rspec/
    when: 'always'

5.7 cache:policy

要更改缓存的上传和下载行为，请使用cache:policy关键字。默认情况下，作业在作业开始时下载缓存，并在作业结束时将更改上传到缓存。此缓存样式是pull-push策略（默认）。

要将作业设置为仅在作业开始时下载缓存，但在作业完成时从不上传更改，请使用cache:policy:pull.

要将作业设置为仅在作业完成时上传缓存，但在作业开始时从不下载缓存，请使用cache:policy:push.

pull当您有许多并行执行的作业使用相同的缓存时，请使用该策略。此策略可加快作业执行并减少缓存服务器上的负载。您可以使用具有push策略的作业来构建缓存。

必须与一起使用cache: path，否则不会缓存任何内容。

示例cache:policy：

prepare-dependencies-job:
  stage: build
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: push
  script:
    - echo "This job only downloads dependencies and builds the cache."
    - echo "Downloading dependencies..."

faster-test-job:
  stage: test
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - echo "This job script uses the cache, but does not update it."
    - echo "Running tests..."

6. coverage

coverage与自定义正则表达式一起使用来配置如何从作业输出中提取代码覆盖率。如果作业输出中至少有一行与正则表达式匹配，则覆盖率将显示在 UI 中。

为了从匹配中提取代码覆盖率值，GitLab 使用这个较小的正则表达式：\d+(.\d+)?.

示例coverage：

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

7. dast_configuration

使用dast_configuration关键字指定要在 CI/CD 配置中使用的站点配置文件和扫描程序配置文件。必须首先在项目中创建这两个配置文件。作业的阶段必须是dast。

示例dast_configuration：

stages:
  - build
  - dast

include:
  - template: DAST.gitlab-ci.yml

dast:
  dast_configuration:
    site_profile: "Example Co"
    scanner_profile: "Quick Passive Test"

8. dependencies

使用dependencies关键字定义要从中获取工件的作业列表。您还可以设置一个作业以完全不下载任何工件。

如果您不使用dependencies，则之前阶段的所有工件都将传递给每个作业。

示例dependencies：

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
  environment: production

在此示例中，两个作业具有工件：build osx和build linux. 执行时，会在构建的上下文中下载并提取test osx来自的工件。build osx同样的事情也发生test linux在build linux.

9. environment

用于environment定义作业部署到的环境。

示例environment：

deploy to production:
  stage: deploy
  script: git push production HEAD:main
  environment: production

9.1 environment:name

为环境设置名称。

常见的环境名称是qa、staging和production，但您可以使用任何名称。

示例environment:name：

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

9.2 environment:url

为环境设置 URL 。

示例environment:url：

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

附加细节：

作业完成后，您可以通过选择合并请求、环境或部署页面中的按钮来访问 URL。

9.3 environment:on_stop

关闭（停止）环境可以使用on_stop定义的关键字来实现environment。它声明了一个运行以关闭环境的不同作业。

9.4 environment:action

使用action关键字指定作业与环境的交互方式。

价值	描述
start	默认值。指示作业启动环境。部署是在作业开始后创建的。
prepare	表示作业只是准备环境。它不会触发部署。阅读有关准备环境的更多信息。
stop	指示作业停止部署。有关更多详细信息，请阅读停止环境。
verify	表示作业仅验证环境。它不会触发部署。阅读有关验证环境的更多信息。
access	表示作业仅访问环境。它不会触发部署。阅读有关访问环境的更多信息。

9.5 environment:auto_stop_in

关键字指定环境的auto_stop_in生命周期。当环境过期时，GitLab 会自动停止它。示例environment:auto_stop_in：

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    auto_stop_in: 1 day

创建环境时review_app，环境的生命周期设置为1 day。每次部署评论应用程序时，该生命周期也会重置为1 day.

9.6 environment:kubernetes

使用kubernetes关键字将部署配置到与您的项目关联的Kubernetes 集群。

示例environment:kubernetes：

deploy:
  stage: deploy
  script: make deploy-app
  environment:
    name: production
    kubernetes:
      namespace: production

9.7 environment:deployment_tier

使用deployment_tier关键字指定部署环境的层。示例environment:deployment_tier：

deploy:
  script: echo
  environment:
    name: customer-portal
    deployment_tier: production

9.8 Dynamic environments

使用 CI/CD变量动态命名环境。例如：

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

该deploy as review app作业被标记为部署以动态创建review/$CI_COMMIT_REF_SLUG环境。$CI_COMMIT_REF_SLUG 是跑步者设置的CI/CD 变量。该 $CI_ENVIRONMENT_SLUG变量基于环境名称，但适合包含在 URL 中。如果deploy as review app作业在名为的分支中运行 pow，则可以使用类似的 URL 访问此环境https://review-pow.example.com/。

10. extends

用于extends重用配置部分。它是YAML 锚点的替代品，并且更加灵活和可读。

示例extends：

.tests:
  script: rake test
  stage: test
  only:
    refs:
      - branches

rspec:
  extends: .tests
  script: rake rspec
  only:
    variables:
      - $RSPEC

在此示例中，rspec作业使用.tests模板作业中的配置。创建管道时，GitLab：

基于键执行反向深度合并。
.tests将内容与rspec作业合并。
不合并键的值。

结果是这个rspec工作：

rspec:
  script: rake rspec
  stage: test
  only:
    refs:
      - branches
    variables:
      - $RSPEC

11. image

用于image指定作业在其中运行的 Docker 映像。

示例image：

default:
  image: ruby:3.0

rspec:
  script: bundle exec rspec

rspec 2.7:
  image: registry.example.com/my-group/my-project/ruby:2.7
  script: bundle exec rspec

11.1 image:name

作业运行所在的 Docker 镜像的名称。类似于单独image使用。示例image:name：

image:
  name: "registry.example.com/my/image:latest"

11.2 image:entrypoint

作为容器入口点执行的命令或脚本。示例image:entrypoint：

image:
  name: super/sql:experimental
  entrypoint: [""]

11.3 image:pull_policy

运行程序用于获取 Docker 映像的拉取策略。

job1:
  script: echo "A single pull policy."
  image:
    name: ruby:3.0
    pull_policy: if-not-present

job2:
  script: echo "Multiple pull policies."
  image:
    name: ruby:3.0
    pull_policy: [always, if-not-present]

附加细节：

如果运行器不支持定义的拉取策略，则作业将失败并出现类似于以下内容的错误： ERROR: Job failed (system failure): the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never])。

12. inherit

用于控制默认关键字和变量inherit的继承。

12.1 inherit:default

用于控制默认关键字inherit:default的继承。

default:
  retry: 2
  image: ruby:3.0
  interruptible: true

job1:
  script: echo "This job does not inherit any default keywords."
  inherit:
    default: false

job2:
  script: echo "This job inherits only the two listed default keywords. It does not inherit 'interruptible'."
  inherit:
    default:
      - retry
      - image

12.2 inherit:variables

用于控制全局变量关键字inherit:variables的继承。

variables:
  VARIABLE1: "This is variable 1"
  VARIABLE2: "This is variable 2"
  VARIABLE3: "This is variable 3"

job1:
  script: echo "This job does not inherit any global variables."
  inherit:
    variables: false

job2:
  script: echo "This job inherits only the two listed global variables. It does not inherit 'VARIABLE3'."
  inherit:
    variables:
      - VARIABLE1
      - VARIABLE2

13. interruptible

interruptible如果在作业完成之前启动较新的管道时应取消作业，则使用此选项。

stages:
  - stage1
  - stage2
  - stage3

step-1:
  stage: stage1
  script:
    - echo "Can be canceled."
  interruptible: true

step-2:
  stage: stage2
  script:
    - echo "Can not be canceled."

step-3:
  stage: stage3
  script:
    - echo "Because step-2 can not be canceled, this step can never be canceled, even though it's set as interruptible."
  interruptible: true

在此示例中，新管道导致正在运行的管道为：

取消，如果只是step-1正在运行或挂起。未取消，step-2开始后。

14. needs

用于needs乱序执行作业。使用的作业之间的关系needs可以可视化为有向无环图。

您可以忽略阶段排序并运行一些作业，而无需等待其他作业完成。多个阶段的作业可以同时运行。

linux:build:
  stage: build
  script: echo "Building linux..."

mac:build:
  stage: build
  script: echo "Building mac..."

lint:
  stage: test
  needs: []
  script: echo "Linting..."

linux:rspec:
  stage: test
  needs: ["linux:build"]
  script: echo "Running rspec on linux..."

mac:rspec:
  stage: test
  needs: ["mac:build"]
  script: echo "Running rspec on mac..."

production:
  stage: deploy
  script: echo "Running production..."
  environment: production

这个例子创建了四个执行路径：

Linter：lint作业立即运行，无需等待build阶段完成，因为它不需要 ( needs: [])。 Linux 路径：作业完成后linux:rspec立即运行linux:build ，无需等待mac:build完成。 macOS 路径：作业完成后mac:rspec立即运行mac:build ，无需等待linux:build完成。该production作业会在所有先前的作业完成后立即运行： linux:build、linux:rspec、mac:build、mac:rspec。

14.1 needs:artifacts

当作业使用needs时，默认情况下它不再从先前阶段下载所有工件，因为作业needs可以在早期阶段完成之前开始。needs您只能从配置中列出的作业下载工件 needs。

使用artifacts: true（默认）或artifacts: false控制何时在使用needs.

test-job1:
  stage: test
  needs:
    - job: build_job1
      artifacts: true

test-job2:
  stage: test
  needs:
    - job: build_job2
      artifacts: false

test-job3:
  needs:
    - job: build_job1
      artifacts: true
    - job: build_job2
    - build_job3

在这个例子中：

作业test-job1下载build_job1工件该test-job2作业不会下载build_job2工件。该test-job3作业从所有三个下载工件build_jobs，因为对于所有三个所需的作业，artifacts是true或默认为。true

14.2 needs:project

用于needs:project从其他管道中的最多五个作业下载工件。工件是从指定 ref 的最新成功管道下载的。needs要指定多个作业，请将每个作业添加为关键字下的单独数组项。

如果有指定 ref 的管道正在运行，则作业needs:project 不会等待管道完成。相反，该作业从成功完成的最新管道下载工件。

build_job:
  stage: build
  script:
    - ls -lhR
  needs:
    - project: namespace/group/project-name
      job: build-1
      ref: main
      artifacts: true
    - project: namespace/group/project-name-2
      job: build-2
      ref: main
      artifacts: true

14.3 needs:pipeline:job

子管道可以从其父管道中的作业或同一父子管道层次结构中的另一个子管道下载工件。

父管道 ( .gitlab-ci.yml)：

create-artifact:
  stage: build
  script: echo "sample artifact" > artifact.txt
  artifacts:
    paths: [artifact.txt]

child-pipeline:
  stage: test
  trigger:
    include: child.yml
    strategy: depend
  variables:
    PARENT_PIPELINE_ID: $CI_PIPELINE_ID

子管道 ( child.yml)： ``` use-artifact: script: cat artifact.txt needs:
- pipeline: $PARENT_PIPELINE_ID job: create-artifact ```

14.4 needs:optional

要需要管道中有时不存在的作业，请添加optional: true 到needs配置中。如果未定义，optional: false则为默认值。

使用rules、only或except的作业可能并不总是添加到管道中。GitLabneeds在启动管道之前检查关系：

如果有需求条目optional: true并且管道中存在所需的作业，则作业会在开始之前等待它完成。如果所需的工作不存在，则可以在满足所有其他需求要求时开始该工作。如果该needs部分仅包含可选作业，并且没有将任何作业添加到管道，则作业将立即启动（与空needs条目相同：） needs: []。如果需要的作业有optional: false，但未添加到管道中，则管道无法启动，并出现类似于以下内容的错误：’job1’ job needs ‘job2’ job, but it was not added to the pipeline。

build-job:
  stage: build

test-job1:
  stage: test

test-job2:
  stage: test
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-job:
  stage: deploy
  needs:
    - job: test-job2
      optional: true
    - job: test-job1
  environment: production

review-job:
  stage: deploy
  needs:
    - job: test-job2
      optional: true
  environment: review

在这个例子中：

build-job, test-job1, 并按test-job2阶段顺序开始。当分支是默认分支时，test-job2被添加到管道中，所以： deploy-job等待两者test-job1并test-job2完成。 review-job等待test-job2完成。当分支不是默认分支时，test-job2不会添加到管道中，所以： deploy-job只等待test-job1完成，不等待丢失的test-job2. review-job没有其他需要的工作并立即开始（与build-job），例如needs: []。

14.5 needs:pipeline

needs:pipeline您可以使用关键字将管道状态从上游管道镜像到桥接作业。默认分支的最新管道状态被复制到桥接作业。

upstream_bridge:
  stage: test
  needs:
    pipeline: other/project

15. only/except

only并且except没有被积极开发。rules是控制何时向管道添加作业的首选关键字。

您可以使用only和except控制何时将作业添加到管道。

用于only定义作业何时运行。
用于except定义作业何时不运行。

15.1 only:refs/except:refs

使用only:refsandexcept:refs关键字来控制何时根据分支名称或管道类型将作业添加到管道。

only:refs并且except:refs没有被积极开发。rules:if 是使用 refs、正则表达式或变量来控制何时将作业添加到管道时的首选关键字。

job1:
  script: echo
  only:
    - main
    - /^issue-.*$/
    - merge_requests

job2:
  script: echo
  except:
    - main
    - /^stable-branch.*$/
    - schedules

15.2 only:variables/except:variables

根据CI/CD 变量的状态，使用only:variablesorexcept:variables关键字控制何时将作业添加到管道。

only:variables并且except:variables没有被积极开发。rules:if 是使用 refs、正则表达式或变量来控制何时将作业添加到管道时的首选关键字。

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

15.3 only:changes/except:changes

当 Git 推送事件修改文件时，使用changes关键字 withonly运行作业或except跳过作业。

changes在具有以下引用的管道中使用：

branches
external_pull_requests
merge_requests（请参阅有关使用only:changes合并请求管道的其他详细信息）

only:changes并且except:changes没有被积极开发。rules:changes 是使用更改的文件来控制何时将作业添加到管道时的首选关键字。

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  only:
    refs:
      - branches
    changes:
      - Dockerfile
      - docker/scripts/*
      - dockerfiles/**/*
      - more_scripts/*.{rb,py,sh}
      - "**/*.json"

15.4 only:kubernetes/except:kubernetes

当 Kubernetes 服务在项目中处于活动状态时，使用only:kubernetes或except:kubernetes控制是否将作业添加到管道中。

only:refs并且except:refs没有被积极开发。rules:if 与预定义的 CI/CD 变量一起使用，CI_KUBERNETES_ACTIVE以控制当 Kubernetes 服务在项目中处于活动状态时是否将作业添加到管道中。

deploy:
  only:
    kubernetes: active

16. pages

用于pages定义将静态内容上传到 GitLab的GitLab Pages作业。然后将内容作为网站发布。

pages:
  stage: deploy
  script:
    - mkdir .public
    - cp -r * .public
    - mv .public public
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  environment: production

此示例将所有文件从项目的根目录移动到该public/目录。.public解决方法是因此不会cp在public/无限循环中复制到自身。

17. parallel

用于parallel在单个管道中并行运行作业多次。

必须存在多个运行器，或者必须将单个运行器配置为同时运行多个作业。

并行作业从job_name 1/N到依次命名job_name N/N。

test:
  script: rspec
  parallel: 5

17.1 parallel:matrix

用于parallel:matrix在单个管道中并行运行多个作业，但每个作业实例具有不同的变量值。

必须存在多个运行器，或者必须将单个运行器配置为同时运行多个作业。

deploystacks:
  stage: deploy
  script:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: aws
        STACK:
          - monitoring
          - app1
          - app2
      - PROVIDER: ovh
        STACK: [monitoring, backup, app]
      - PROVIDER: [gcp, vultr]
        STACK: [data, processing]
  environment: $PROVIDER/$STACK

18. release

用于release创建发布。

发布作业必须有权访问release-cli，它必须位于$PATH.

如果你使用Docker executor，你可以使用 GitLab Container Registry 中的这个镜像：registry.gitlab.com/gitlab-org/release-cli:latest

如果您使用Shell 执行程序或类似程序，请安装release-cli在注册运行程序的服务器上。

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG                  # Run this job when a tag is created manually
  script:
    - echo "Running the release job."
  release:
    tag_name: $CI_COMMIT_TAG
    name: 'Release $CI_COMMIT_TAG'
    description: 'Release created using the release-cli.'

此示例创建一个版本：

当你推送一个 Git 标签时。当您在 UI 中的Repository > Tags添加 Git 标记时。

18.1 release:tag_name

必需的。发布的 Git 标记。

如果项目中尚不存在该标签，则在发布的同时创建该标签。新标签使用与管道关联的 SHA。

示例release:tag_name：

在项目中添加新标签时创建发布：

使用$CI_COMMIT_TAGCI/CD 变量作为tag_name. 使用rules:if或only: tags将作业配置为仅对新标签运行。

job:
  script: echo "Running the release job for the new tag."
  release:
    tag_name: $CI_COMMIT_TAG
    description: 'Release description'
  rules:
    - if: $CI_COMMIT_TAG

要同时创建发布和新标签，您rules或不only 应该将作业配置为仅针对新标签运行。语义版本控制示例：

job:
  script: echo "Running the release job and creating a new tag."
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: 'Release description'
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

18.2 release:tag_message

如果标签不存在，则新创建的标签将使用指定的消息进行注释tag_message。如果省略，则会创建一个轻量级标签。

  release_job:
    stage: release
    release:
      tag_name: $CI_COMMIT_TAG
      description: 'Release description'
      tag_message: 'Annotated tag message'

18.3 release:name

发布名称。如果省略，则使用的值填充它release: tag_name。

  release_job:
    stage: release
    release:
      name: 'Release $CI_COMMIT_TAG'

18.4 release:description

发布的详细描述。

job:
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: './path/to/CHANGELOG.md'

18.5 elease:ref

ref用于发布，如果尚不release: tag_name存在。

18.6 release:milestones

与发布相关联的每个里程碑的标题。

18.7 release:released_at

发布准备就绪的日期和时间。

released_at: '2021-03-15T08:00:00Z'

18.8 release:assets:links

用于在发布release:assets:links中包含资产链接。

assets:
  links:
    - name: 'asset1'
      url: 'https://example.com/assets/1'
    - name: 'asset2'
      url: 'https://example.com/assets/2'
      filepath: '/pretty/url/1' # optional
      link_type: 'other' # optional

19. resource_group

用于resource_group创建资源组，以确保同一项目的不同管道之间的作业互斥。

例如，如果属于同一资源组的多个作业同时排队，则只有一个作业启动。其他作业等到resource_group空闲为止。

资源组的行为类似于其他编程语言中的信号量。

您可以为每个环境定义多个资源组。例如，在部署到物理设备时，您可能有多个物理设备。每个设备都可以部署到，但在任何给定时间每个设备只能进行一次部署。

示例resource_group：

deploy-to-production:
  script: deploy
  resource_group: production

在此示例deploy-to-production中，两个独立管道中的两个作业永远不能同时运行。因此，您可以确保不会在生产环境中发生并发部署。

20. retry

用于retry配置作业失败时重试的次数。如果未定义，则默认为0并且作业不会重试。

当一个作业失败时，该作业最多被处理两次，直到它成功或达到最大重试次数。

默认情况下，所有失败类型都会导致作业重试。用于retry:when 选择要重试的故障。

test:
  script: rspec
  retry: 2

20.1 retry:when

使用retry:whenwithretry:max仅针对特定的失败案例重试作业。 retry:max是重试的最大次数，例如retry，并且可以是 0，1，或2。

可能的输入：

单个故障类型，或一个或多个故障类型的数组：

always：重试任何失败（默认）。
unknown_failure: 失败原因未知时重试。
script_failure: 脚本失败时重试。
api_failure: 重试 API 失败。
stuck_or_timeout_failure：当作业卡住或超时时重试。
runner_system_failure：如果存在运行器系统故障（例如，作业设置失败），请重试。
runner_unsupported：如果运行器不受支持，请重试。
stale_schedule：如果无法执行延迟的作业，请重试。
job_execution_timeout：如果脚本超过为作业设置的最大执行时间，请重试。
archived_failure：如果作业已存档且无法运行，请重试。
unmet_prerequisites：如果作业未能完成必备任务，请重试。
scheduler_failure：如果调度程序未能将作业分配给运行器，则重试。
data_integrity_failure：如果检测到结构完整性问题，请重试。

test:
  script: rspec
  retry:
    max: 2
    when: runner_system_failure

21. rules

用于rules在管道中包含或排除作业。

规则在创建管道时进行评估，并按顺序评估，直到第一次匹配。找到匹配项后，该作业将包含在管道中或从管道中排除，具体取决于配置。

您不能在规则中使用作业脚本中创建的 dotenv 变量，因为在任何作业运行之前都会评估规则。

rules替换only/except，并且它们不能在同一个工作中一起使用。如果您将一项作业配置为同时使用这两个关键字，GitLab 会返回key may not be used with rules错误。

rules接受定义的规则数组：

if
changes
exists
allow_failure
variables
when 您可以将多个关键字组合在一起以形成复杂的规则。

作业被添加到管道中：

如果if、changes或exists规则匹配并且还具有when: on_success（默认） when: delayed、或when: always。如果达到的规则只有when: on_success, when: delayed, 或when: always. 该作业未添加到管道中：

如果没有规则匹配。如果规则匹配并且具有when: never. 您可以使用!reference标签在不同的作业中重用rules配置。

21.1 rules:if

使用rules:if子句指定何时将作业添加到管道：

如果if陈述为真，则将作业添加到管道中。
如果if陈述为真，但与结合使用when: never，则不要将作业添加到管道中。
如果没有if陈述为真，请不要将作业添加到管道中。

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME != $CI_DEFAULT_BRANCH
      when: never
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/
      when: manual
      allow_failure: true
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME

21.2 rules:changes

用于rules:changes通过检查对特定文件的更改来指定何时将作业添加到管道。

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - Dockerfile
      when: manual
      allow_failure: true

如果管道是合并请求管道，请检查Dockerfile更改。
如果Dockerfile已更改，请将作业作为手动作业添加到管道中，即使未触发作业，管道也会继续运行 ( allow_failure: true)。
如果Dockerfile未更改，则不要将作业添加到任何管道（与相同when: never）。
rules:changes:pathsrules:changes与没有任何子项相同。

21.3 rules:changes:paths

用于rules:changes指定仅在更改特定文件时将作业添加到管道中，并用于rules:changes:paths指定文件。

rules:changes:pathsrules:changes与不使用任何子项相同。所有其他详细信息和相关主题都是相同的。

docker-build-1:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - Dockerfile

docker-build-2:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        paths:
          - Dockerfile

21.4 rules:changes:compare_to

用于rules:changes:compare_to指定对 . 下列出的文件的更改与哪个 ref 进行比较rules:changes:paths。

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        paths:
          - Dockerfile
        compare_to: 'refs/heads/branch1'

21.5 rules:exists

用于exists在存储库中存在某些文件时运行作业。

job:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - exists:
        - Dockerfile

21.6 rules:allow_failure

使用allow_failure: trueinrules允许作业在不停止管道的情况下失败。

您也可以使用allow_failure: true手动作业。管道继续运行，无需等待手动作业的结果。allow_failure: false 与when: manualin 规则结合使用会导致管道在继续之前等待手动作业运行。

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH
      when: manual
      allow_failure: true

21.7 rules:variables

用于variables为rules特定条件定义变量。

job:
  variables:
    DEPLOY_VARIABLE: "default-deploy"
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:                              # Override DEPLOY_VARIABLE defined
        DEPLOY_VARIABLE: "deploy-production"  # at the job level.
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # Define a new variable.
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"

22. script

用于script指定运行器要执行的命令。

除触发作业外的所有作业都需要script关键字。

job1:
  script: "bundle exec rspec"

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

23. secrets

用于secrets指定CI/CD 机密以：

从外部机密提供程序中检索。在作业中作为CI/CD 变量提供（默认file类型）。此关键字必须与一起使用secrets:vault。

23.1 secrets:vault

用于secrets:vault指定HashiCorp Vault提供的机密。

job:
  secrets:
    DATABASE_PASSWORD:  # Store the path to the secret in this CI/CD variable
      vault:  # Translates to secret: `ops/data/production/db`, field: `password`
        engine:
          name: kv-v2
          path: ops
        path: production/db
        field: password

23.2 secrets:file

用于secrets:file配置要存储为 CI/CD 变量file或variable类型 CI/CD 变量的密钥

默认情况下，秘密作为file类型 CI/CD 变量传递给作业。密钥的值存储在文件中，变量包含文件的路径。

如果您的软件不能使用file类型 CI/CD 变量，请设置file: false为将秘密值直接存储在变量中。

24. services

用于services指定要在其中运行脚本的附加 Docker 映像。该services映像链接到image关键字中指定的映像。

24.1 service:pull_policy

运行程序用于获取 Docker 映像的拉取策略。

25. stage

用于stage定义作业在哪个阶段运行。同一阶段的作业可以stage并行执行（请参阅其他详细信息）。

如果stage未定义，则作业test默认使用阶段。

stages:
  - build
  - test
  - deploy

job1:
  stage: build
  script:
    - echo "This job compiles code."

job2:
  stage: test
  script:
    - echo "This job tests the compiled code. It runs when the build stage completes."

job3:
  script:
    - echo "This job also runs in the test stage".

job4:
  stage: deploy
  script:
    - echo "This job deploys the code. It runs when the test stage completes."
  environment: production

25.1 stage: .pre

使用.pre阶段使作业在管道开始时运行。.pre始终是管道中的第一阶段。用户定义的阶段在.pre. 您不必在中.pre定义stages。

如果管道仅包含.preor.post阶段中的作业，则它不会运行。在不同的阶段必须至少有一项其他工作。

25.2 stage: .post

使用.post阶段使作业在管道末端运行。.post 始终是管道中的最后一个阶段。用户定义的阶段在.post. 您不必在中.post定义stages。

如果管道仅包含.preor.post阶段中的作业，则它不会运行。在不同的阶段必须至少有一项其他工作。

stages:
  - build
  - test

job1:
  stage: build
  script:
    - echo "This job runs in the build stage."

last-job:
  stage: .post
  script:
    - echo "This job runs in the .post stage, after all other stages."

job2:
  stage: test
  script:
    - echo "This job runs in the test stage."

26. tags

用于tags从项目可用的所有运行器列表中选择特定运行器。

注册跑步者时，您可以指定跑步者的标签，例如ruby、postgres或development。要拿起并运行一项工作，必须为工作中列出的每个标签分配一个跑步者。

job:
  tags:
    - ruby
    - postgres

27. timeout

用于timeout为特定作业配置超时。如果作业运行时间超过超时，则作业失败。

作业级超时可以长于项目级超时。但不能超过跑步者的超时时间。

build:
  script: build.sh
  timeout: 3 hours 30 minutes

test:
  script: rspec
  timeout: 3h 30m

28. trigger

用于trigger声明作业是“触发作业”，它启动下游管道，该管道是：

多项目管道。
一个子管道。触发作业只能使用一组有限的 GitLab CI/CD 配置关键字。可用于触发作业的关键字是：
trigger.
stage.
allow_failure.
rules.
only和except。
when（仅具有、或的on_success值on_failure）always。
extends.
needs，但不是needs:project。

trigger-multi-project-pipeline:
  trigger: my-group/my-project

28.1 trigger:include

用于trigger:include声明作业是启动子管道的“触发作业” 。

用于trigger:include:artifact触发动态子管道。

trigger-child-pipeline:
  trigger:
    include: path/to/child-pipeline.gitlab-ci.yml

28.2 trigger:project

用于trigger:project声明作业是启动多项目管道的“触发作业” 。

默认情况下，多项目管道会触发默认分支。用于trigger:branch 指定不同的分支。

trigger-multi-project-pipeline:
  trigger:
    project: my-group/my-project

28.3 trigger:strategy

用于trigger:strategy强制作业在标记为成功trigger之前等待下游管道完成。

此行为与默认行为不同，默认行为是在创建下游管道后立即将trigger作业标记为成功。

此设置使您的管道执行线性而不是并行。

trigger_job:
  trigger:
    include: path/to/child-pipeline.yml
    strategy: depend

28.4 trigger:forward

用于trigger:forward指定要转发到下游管道的内容。您可以控制转发到父子管道和多项目管道的内容。

variables: # default variables for each job
  VAR: value

# Default behavior:
# - VAR is passed to the child
# - MYVAR is not passed to the child
child1:
  trigger:
    include: .child-pipeline.yml

# Forward pipeline variables:
# - VAR is passed to the child
# - MYVAR is passed to the child
child2:
  trigger:
    include: .child-pipeline.yml
    forward:
      pipeline_variables: true

# Do not forward YAML variables:
# - VAR is not passed to the child
# - MYVAR is not passed to the child
child3:
  trigger:
    include: .child-pipeline.yml
    forward:
      yaml_variables: false

29. variables

CI/CD 变量是传递给作业的可配置值。用于variables创建自定义变量。

变量始终在script、before_script和after_script命令中可用。您还可以在某些工作关键字中使用变量作为输入。

variables:
  DEPLOY_SITE: "https://example.com/"

deploy_job:
  stage: deploy
  script:
    - deploy-script --url $DEPLOY_SITE --path "/"
  environment: production

deploy_review_job:
  stage: deploy
  variables:
    REVIEW_PATH: "/review"
  script:
    - deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
  environment: production

29.1 variables:description

使用description关键字定义手动运行管道时预填充的管道级（全局）变量。

必须与value, 一起用于变量值。

variables:
  DEPLOY_ENVIRONMENT:
    value: "staging"
    description: "The deployment target. Change this variable to 'canary' or 'production' if needed."

30 when

用于when配置作业运行的条件。如果未在作业中定义，则默认值为when: on_success.

可能的输入：

on_success（默认）：仅在早期阶段的所有作业都成功或具有allow_failure: true.
manual：仅在手动触发时运行作业。
always：无论早期阶段的作业状态如何，都运行作业。也可用于workflow:rules.
on_failure：仅当至少一个早期阶段的作业失败时才运行作业。
delayed：将作业的执行延迟指定的持续时间。
never: 不要运行作业。只能在rules部分或中使用workflow: rules。

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
  environment: production

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

在此示例中，脚本：

cleanup_build_job仅在build_job失败时执行。
cleanup_job无论成功或失败，始终作为管道中的最后一步执行。
deploy_job在 GitLab UI 中手动运行时执行。附加细节：
在GitLab 13.5 及更高版本中，您可以when:manual在同一作业中使用trigger. 在 GitLab 13.4 及更早版本中，将它们一起使用会导致错误jobs:#{job-name} when should be on_success, on_failure or always。
allow_failure更改为truewith的默认行为when: manual。但是，如果您使用when: manualwith rules，则allow_failure默认为false.

参考：

查看.gitlab-ci.yml文件的完整语法。

目录

概念

关键词

全局关键字

1. default

2. include

2.1 include:local

2.2 include:file

2.3 include:remote

2.4 include:template

3. stages

4. workflow

4.1 workflow:rules

4.2 workflow:rules:variables

工作关​​键词

1. after_script

2. allow_failure

2.1 allow_failure:exit_codes

3、artifacts

3.1 artifacts:paths

3.2 artifacts:exclude

3.3 artifacts:expire_in

3.4 artifacts:expose_as

3.5 artifacts:name

3.6 artifacts:public

3.7 artifacts:reports

3.8 artifacts:untracked

3.9 artifacts:when

4. before_script

5. cache

5.1 cache:paths

5.2 cache:key

5.3 cache:key:files

5.4 cache:key:prefix

5.5 cache:untracked

5.6 cache:when

5.7 cache:policy

6. coverage

7. dast_configuration

8. dependencies

9. environment

9.1 environment:name

9.2 environment:url

9.3 environment:on_stop

9.4 environment:action

9.5 environment:auto_stop_in

9.6 environment:kubernetes

9.7 environment:deployment_tier

9.8 Dynamic environments

10. extends

11. image

11.1 image:name

11.2 image:entrypoint

11.3 image:pull_policy

12. inherit

12.1 inherit:default

12.2 inherit:variables

13. interruptible

14. needs

14.1 needs:artifacts

14.2 needs:project

14.3 needs:pipeline:job

14.4 needs:optional

14.5 needs:pipeline

15. only/except

15.1 only:refs/except:refs

15.2 only:variables/except:variables

15.3 only:changes/except:changes

15.4 only:kubernetes/except:kubernetes

16. pages

17. parallel

17.1 parallel:matrix

18. release

18.1 release:tag_name

18.2 release:tag_message

18.3 release:name

18.4 release:description

18.5 elease:ref

18.6 release:milestones

18.7 release:released_at

工作关键词