Miykael_xxm · 9dc8aabf
隐藏空白更改
内联并排

Showing with 774 addition and 1037 deletion

docs/ci/yaml.md docs/ci/yaml.md +774 -1037

未找到文件。
--- a/docs/ci/yaml.md
+++ b/docs/ci/yaml.md
@@ -2783,1480 +2783,1223 @@ job1:
  coverage: '/Code coverage: \d+\.\d+/'
 ```

-如果流水线任务输出中至少有一行与正则表达式匹配，则覆盖率会显示在 UI 中。
-如果流水线任务输出中有多个匹配的行，则使用最后一行。
-对于匹配的行，第一次出现 `\d+(\.\d+)?` 是代码覆盖率。
-前导零被删除。
+当流水线任务输出中至少有一行与正则表达式匹配时，则覆盖率会显示在 UI 中。如果流水线任务输出中有多个匹配的行，则使用最后一行。对于匹配的行，第一次出现 `\d+(\.\d+)?` 是代码覆盖率。前面的空内容会被删除。

-[子流水线](../parent_child_pipelines.md) 的覆盖率输出未记录
-或显示。检查[相关问题](https://gitlab.com/gitlab-org/gitlab/-/issues/280818)
-更多细节。
+子流水线的覆盖率输出并未记录或显示

-###`重试`
+### `retry`[](#retry)

-> [介绍](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3515) 在 GitLab 11.5 中，你可以控制重试哪些故障。
+使用 `retry` 配置一个流水线任务失败时的重试次数。

-使用 `retry` 配置一个流水线任务的重试次数
-失败的情况。
+当一个流水线任务失败时，该流水线任务会被重新处理，直至达到由 `retry` 关键字指定限制的次数。

-当一个流水线任务失败时，该流水线任务被重新处理，
-直到达到由 `retry` 关键字指定的限制。
-
-如果 `retry` 设置为 `2`，并且流水线任务在第二次运行（第一次重试）中成功，则不会重试。
-`retry` 值必须是一个正整数，从 `0` 到 `2`
-（最多重试两次，总共运行三次）。
+如果 `retry` 设置为 `2`，并且流水线任务在第二次运行（第一次重试）中成功，则不会再次重试。`retry` 值必须是一个正整数，从 `0` 到 `2`（最多重试两次，总共运行三次）。

 以下示例重试所有失败情况：

 ```yaml
-测试：
-  脚本：rspec
-  重试：2
-``
+test:
+  script: rspec
+  retry: 2
+```

-默认情况下，在所有失败情况下都会重试流水线任务。为了更好地控制
-对于重试失败，“重试”可以是具有以下键的散列：
+默认情况下，在所有失败情况下都会重试流水线任务。为了更好地控制重试失败，`retry` 可以是具有以下键的散列：

 - `max`：最大重试次数。
- `when`：要重试的失败案例。
+- `when`：要重试的失败 case。

-仅重试运行器系统故障最多两次：
+当 Runner 系统故障时最多重试两次，你可以这样做：

 ```yaml
-测试：
-  脚本：rspec
-  重试：
-    最大：2
-    时间：runner_system_failure
-``
+test:
+  script: rspec
+  retry:
+    max: 2
+    when: runner_system_failure
+```

-如果除了流道系统故障之外还有其他故障，流水线任务
-不重试。
+如果除了 Runner 系统故障之外还有其他故障，流水线任务不会重试。

-要重试多个失败案例，`when` 也可以是一个失败数组：
+要重试多个失败 cases，`when` 也可以是一个失败 cases 数组：

 ```yaml
-测试：
-  脚本：rspec
-  重试：
-    最大：2
-    什么时候：
+test:
+  script: rspec
+  retry:
+    max: 2
+    when:
      - runner_system_failure
-      - 卡住_or_timeout_failure
-``
+      - stuck_or_timeout_failure
+```

 `when` 的可能值为：

-<!--
-  如果你更改以下任何值，请确保更新 `RETRY_WHEN_IN_DOCUMENTATION`
-  `spec/lib/gitlab/ci/config/entry/retry_spec.rb` 中的数组。
-  那里的测试确保所有记录在案
-  值作为配置选项有效，因此应始终
-  与本文档保持同步。
-->
-
 - `always`：在任何失败时重试（默认）。
 - `unknown_failure`：失败原因未知时重试。
 - `script_failure`：脚本失败时重试。
 - `api_failure`：API 失败时重试。
 - `stuck_or_timeout_failure`：当流水线任务卡住或超时时重试。
 - `runner_system_failure`：如果存在运行器系统故障（例如，流水线任务设置失败），则重试。
- `missing_dependency_failure`：如果缺少依赖项，请重试。
- `runner_unsupported`：如果跑步者不受支持，则重试。
- `stale_schedule`：如果无法执行延迟的流水线任务，请重试。
+- `missing_dependency_failure`：如果缺少依赖项，则重试。
+- `runner_unsupported`：如果 Runner 不受支持，则重试。
+- `stale_schedule`：如果无法执行延迟的流水线任务，则重试。
 - `job_execution_timeout`：如果脚本超过为流水线任务设置的最大执行时间，则重试。
- `archived_failure`：如果流水线任务已存档且无法运行，请重试。
+- `archived_failure`：如果流水线任务已存档且无法运行，则重试。
 - `unmet_prerequisites`：如果流水线任务未能完成先决任务，则重试。
 - `scheduler_failure`：如果调度程序未能将流水线任务分配给运行程序，则重试。
- `data_integrity_failure`：如果检测到结构完整性问题，请重试。
-
-你可以使用变量指定[特定流水线任务执行阶段的重试次数](../runners/README.md#job-stages-attempts)。
+- `data_integrity_failure`：如果检测到结构完整性问题，则重试。

-###`超时`
+你可以使用变量指定[特定流水线任务执行阶段的重试次数](/docs/ci/runners#job-stages-attempts)。

-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/14887) 在 GitLab 12.3 中。
+### `timeout`[](#timeout)

 使用 `timeout` 为特定流水线任务配置超时。例如：

 ```yaml
-建造：
-  脚本：build.sh
-  超时：3小时30分钟
-
-测试：
-  脚本：rspec
-  超时时间：3h 30m
-``
+build:
+  script: build.sh
+  timeout: 3 hours 30 minutes

-流水线任务级超时可以超过
-[项目级超时](../pipelines/settings.md#timeout) 但不能
-超过跑步者特定的超时时间。
+test:
+  script: rspec
+  timeout: 3h 30m
+```

-###`平行`
+流水线任务级超时可以超过[项目级超时时间](/docs/ci/pipelines/settings#timeout) ，但不能
+超过 Runner 设置的超时时间。

-> [介绍](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21480) 在 GitLab 11.5 中。
+### `parallel`[](#parallel)

-使用 `parallel` 配置要并行运行的流水线任务实例的数量。
-该值可以是 2 到 50。
+使用 `parallel` 配置要并行运行的流水线任务实例的数量。该值可以是 2 到 50。

-`parallel` 关键字创建并行运行的同一流水线任务的 N 个实例。
-它们的命名顺序是从 `job_name 1/N` 到 `job_name N/N`：
+`parallel` 关键字创建并行运行的同一流水线任务的 N 个实例。它们的命名顺序是从 `job_name 1/N` 到 `job_name N/N`：

 ```yaml
-测试：
-  脚本：rspec
-  平行：5
-``
+test:
+  script: rspec
+  parallel: 5
+```

-每个并行流水线任务都有一个“CI_NODE_INDEX”和“CI_NODE_TOTAL”
-[预定义 CI/CD 变量](../variables/README.md#predefined-cicd-variables) 设置。
+每个并行流水线任务都有一个 `CI_NODE_INDEX` 和 `CI_NODE_TOTAL` [预定义 CI/CD 变量](/docs/ci/variables#predefined-cicd-variables) 设置。

-不同的语言和测试套件有不同的方法来实现并行化。
-例如，使用 [Semaphore Test Boosters](https://github.com/renderedtext/test-boosters)
-和 RSpec 并行运行 Ruby 测试：
+不同的语言和测试套件有不同的方法来实现并行。例如，使用 [Semaphore Test Boosters](https://github.com/renderedtext/test-boosters)和 RSpec 并行运行 Ruby 测试：

-```红宝石
-# 宝石文件
-来源“https://rubygems.org”
+```ruby
+# Gemfile
+source 'https://rubygems.org'

-宝石'rspec'
+gem 'rspec'
 gem 'semaphore_test_boosters'
-``
+```

 ```yaml
-测试：
-  并行：3
-  脚本：
-    - 捆
-    - 捆绑执行 rspec_booster --job $CI_NODE_INDEX/$CI_NODE_TOTAL
-``
-
-警告：
-Test Boosters 向作者报告使用统计数据。
+test:
+  parallel: 3
+  script:
+    - bundle
+    - bundle exec rspec_booster --job $CI_NODE_INDEX/$CI_NODE_TOTAL
+```

-然后，你可以导航到新流水线构建的 **Jobs** 选项卡并查看你的 RSpec
-流水线任务分为三个独立的流水线任务。
+> 警告：
+>
+> Test Boosters 会向其作者报告使用统计数据。

-#### 并行`矩阵`流水线任务
+然后，你可以导航到新流水线构建的 **流水线任务** 选项卡，这时你会发现 RSpec 的流水线任务已经分为三个独立的流水线任务。

-> - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/15356) 在 GitLab 13.3 中。
+#### 并行 `matrix` 流水线任务

-使用 `matrix:` 在单个流水线中并行运行流水线任务多次，
-但每个流水线任务实例都有不同的变量值。
-可以有 2 到 50 个流水线任务岗位。
+使用 `matrix:` 在单个流水线中并行运行流水线任务多次，但每个流水线任务实例都有不同的变量值。可以有 2 到 50 个流水线任务。

-流水线任务只有在有多个跑步者或单个跑步者时才能并行运行
-[配置为同时运行多个流水线任务](#use-your-own-runners)。
+流水线任务只有在有多个 Runner 或单个 Runner 被配置为同时运行多个流水线任务时才能并行运行。

-每个流水线任务都获得相同的 `CI_NODE_TOTAL` [CI/CD 变量](../variables/README.md#predefined-cicd-variables) 值和唯一的 `CI_NODE_INDEX` 值。
+每个流水线任务都获得相同的 `CI_NODE_TOTAL` [CI/CD 变量](/docs/ci/variables#predefined-cicd-variables) 值和唯一的 `CI_NODE_INDEX` 值。

 ```yaml
-部署堆栈：
-  阶段：部署
-  脚本：
-    - 垃圾箱/部署
-  平行：
-    矩阵：
-      - 供应商：aws
-        堆：
-          - 监控
-          - 应用程序1
-          - 应用程序2
-      - 提供者：ovh
-        堆栈：[监控、备份、应用程序]
-      - 提供者：[gcp，vultr]
-        堆栈：[数据，处理]
-``
-
-以下示例生成 10 个并行的 `deploystacks` 流水线任务，每个流水线任务具有不同的值
-对于 `PROVIDER` 和 `STACK`：
-
-```明文
-deploystacks：[aws，监控]
-部署堆栈：[aws，app1]
-部署堆栈：[aws，app2]
-deploystacks: [ovh, 监控]
-部署堆栈：[ovh，备份]
-部署堆栈：[ovh，应用程序]
-部署堆栈：[gcp，数据]
-部署堆栈：[gcp，处理]
-部署堆栈：[vultr，数据]
-部署堆栈：[vultr，处理]
-``
-
-流水线任务命名风格[在 GitLab 13.4 中改进](https://gitlab.com/gitlab-org/gitlab/-/issues/230452)。
-
-#####一维`矩阵`流水线任务
-
-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/26362) 在 GitLab 13.5 中。
+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]
+```
+
+上面的例子生成了 10 个并行的 `deploystacks` 流水线任务，对于 `PROVIDER` 和 `STACK`每个流水线任务具有不同的值：
+
+```plaintext
+deploystacks: [aws, monitoring]
+deploystacks: [aws, app1]
+deploystacks: [aws, app2]
+deploystacks: [ovh, monitoring]
+deploystacks: [ovh, backup]
+deploystacks: [ovh, app]
+deploystacks: [gcp, data]
+deploystacks: [gcp, processing]
+deploystacks: [vultr, data]
+deploystacks: [vultr, processing]
+```
+
+##### 一维 `matrix` 流水线任务

 你还可以在单个流水线任务中使用一维矩阵：

 ```yaml
-部署堆栈：
-  阶段：部署
-  脚本：
-    - 垃圾箱/部署
-  平行：
-    矩阵：
-      - 提供商：[aws、ovh、gcp、vultr]
-``
-
-##### 并行`matrix` 触发流水线任务
+deploystacks:
+  stage: deploy
+  script:
+    - bin/deploy
+  parallel:
+    matrix:
+      - PROVIDER: [aws, ovh, gcp, vultr]
+```

-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/270957) 在 GitLab 13.10 中。
+##### 并行 `matrix` 触发流水线任务

-使用 `matrix:` 在单个流水线中多次并行运行 [trigger](#trigger) 流水线任务，
-但每个流水线任务实例都有不同的变量值。
+使用 `matrix:` 在单个流水线中多次并行运行 [trigger](#trigger) 流水线任务，但每个流水线任务实例都有不同的变量值。

 ```yaml
-部署堆栈：
-  阶段：部署
-  扳机：
-    包括：path/to/child-pipeline.yml
-  平行：
-    矩阵：
-      - 供应商：aws
-        堆栈：[监控，app1]
-      - 提供者：ovh
-        堆栈：[监控、备份]
-      - 提供者：[gcp，vultr]
-        堆栈：[数据]
-``
-
-此示例生成 6 个并行的 `deploystacks` 触发器流水线任务，每个流水线任务具有不同的值
-对于 `PROVIDER` 和 `STACK`，它们使用这些变量创建了 6 个不同的子流水线。
+deploystacks:
+  stage: deploy
+  trigger:
+    include: path/to/child-pipeline.yml
+  parallel:
+    matrix:
+      - PROVIDER: aws
+        STACK: [monitoring, app1]
+      - PROVIDER: ovh
+        STACK: [monitoring, backup]
+      - PROVIDER: [gcp, vultr]
+        STACK: [data]
+```

-```明文
-deploystacks：[aws，监控]
-部署堆栈：[aws，app1]
-deploystacks: [ovh, 监控]
-部署堆栈：[ovh，备份]
-部署堆栈：[gcp，数据]
-部署堆栈：[vultr，数据]
-``
+此示例生成 6 个并行的 `deploystacks` 触发器流水线任务，对于 `PROVIDER` 和 `STACK` 每个流水线任务具有不同的值，它们使用这些变量创建了 6 个不同的子流水线。

-###`触发器`
+```plaintext
+deploystacks: [aws, monitoring]
+deploystacks: [aws, app1]
+deploystacks: [ovh, monitoring]
+deploystacks: [ovh, backup]
+deploystacks: [gcp, data]
+deploystacks: [vultr, data]
+```

-> - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/8997) 在 [GitLab Premium](https://about.gitlab.com/pricing/) 11.8。
-> - [移动](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) 在 12.8 中免费使用 GitLab。
+### `trigger`[](#trigger)

-使用 `trigger` 定义下游流水线触发器。当 GitLab 开始一个 `trigger` 流水线任务时，
-创建下游流水线。
+使用 `trigger` 定义下游流水线触发器。当开始一个 `trigger` 流水线任务时，会创建下游流水线。

-带有`trigger` 的流水线任务只能使用[有限的关键字集](../multi_project_pipelines.md#limitations)。
-例如，你不能用 [`script`](#script), [`before_script`](#before_script),
-或 [`after_script`](#after_script)。
+带有`trigger` 的流水线任务只能使用有限的关键字集。例如，你不能用 [`script`](#script)，[`before_script`](#before_script)，或 [`after_script`](#after_script)。

 你可以使用此关键字创建两种不同类型的下游流水线：

- [多项目流水线](../multi_project_pipelines.md#creating-multi-project-pipelines-from-gitlab-ciyml)
- [子流水线](../parent_child_pipelines.md)
+- 多项目流水线
+- 子流水线

-[在 GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/) 及更高版本，你可以
-查看哪个流水线任务触发了下游流水线。在[流水线图](../pipelines/index.md#visualize-pipelines)中，
-将鼠标悬停在下游流水线流水线任务上。
+你可以查看哪个流水线任务触发了下游流水线。在[流水线图](/docs/ci/pipelines#visualize-pipelines)中，并将鼠标悬停在下游流水线流水线任务上即可查看。

-在 [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/201938) 及更高版本中，你
-可以在与 `trigger` 相同的流水线任务中使用 [`when:manual`](#whenmanual)。在 GitLab 13.4 和
-早些时候，将它们一起使用会导致错误 `jobs:#{job-name} when should be on_success, on_failure or always`。
-你[无法使用 API 启动`手动`触发器流水线任务](https://gitlab.com/gitlab-org/gitlab/-/issues/284086)。
+你可以在与 `trigger` 相同的流水线任务中使用 [`when:manual`](#whenmanual)。

-#### 多项目流水线的基本`trigger` 语法
+#### 多项目流水线的基本 `trigger` 语法

-你可以使用 `trigger` 关键字配置下游触发器
-下游项目的完整路径：
+你可以使用 `trigger` 关键字和下游项目的完整路径配置下游触发器：

 ```yaml
-规格：
-  阶段：测试
-  脚本：bundle exec rspec
+rspec:
+  stage: test
+  script: bundle exec rspec

-分期：
-  阶段：部署
-  触发器：我的/部署
-``
+staging:
+  stage: deploy
+  trigger: my/deployment
+```

-#### 多项目流水线的复杂`trigger` 语法
+#### 多项目流水线的复杂 `trigger` 语法

-你可以配置一个 GitLab 用来创建的分支名称
-具有以下功能的下游流水线：
+你可以配置一个用分支名称来创建的具有以下功能的下游流水线：

 ```yaml
-规格：
-  阶段：测试
-  脚本：bundle exec rspec
+rspec:
+  stage: test
+  script: bundle exec rspec

-分期：
-  阶段：部署
-  扳机：
-    项目：我的/部署
-    分支：稳定
-``
+staging:
+  stage: deploy
+  trigger:
+    project: my/deployment
+    branch: stable
+```

 要从触发的流水线镜像状态：

 ```yaml
 trigger_job:
-  扳机：
-    项目：我的/项目
-    策略：依赖
-``
+  trigger:
+    project: my/project
+    strategy: depend
+```

 要从上游流水线镜像状态：

 ```yaml
-上游桥：
-  阶段：测试
-  需要：
-    流水线：其他/项目
-``
-
-#### 子流水线的`trigger` 语法
+upstream_bridge:
+  stage: test
+  needs:
+    pipeline: other/project
+```

-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/16094) 在 GitLab 12.7 中。
+#### 子流水线的 `trigger` 语法

-要创建 [子流水线](../parent_child_pipelines.md)，请指定路径
-包含子流水线配置的 YAML 文件：
+要创建子流水线，请指定包含子流水线配置的 YAML 文件路径：

 ```yaml
 trigger_job:
-  扳机：
-    包括：path/to/child-pipeline.yml
-``
+  trigger:
+    include: path/to/child-pipeline.yml
+```

-类似于[多项目流水线](../multi_project_pipelines.md#mirroring-status-from-triggered-pipeline)，
-可以从触发的流水线中镜像状态：
+类似于多项目流水线，可以从触发的流水线中镜像状态：

 ```yaml
 trigger_job:
-  扳机：
-    包括：
-      - 本地：path/to/child-pipeline.yml
-    策略：依赖
-``
+  trigger:
+    include:
+      - local: path/to/child-pipeline.yml
+    strategy: depend
+```

 ##### 使用生成的配置文件触发子流水线

-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/35632) 在 GitLab 12.9 中。
-
-你还可以从 [动态生成的配置文件](../parent_child_pipelines.md#dynamic-child-pipelines) 触发子流水线：
+你还可以通过动态生成的配置文件触发子流水线：

 ```yaml
-生成配置：
-  阶段：构建
-  脚本：生成-ci-config > 生成-config.yml
-  文物：
-    路径：
-      - 生成的 config.yml
+generate-config:
+  stage: build
+  script: generate-ci-config > generated-config.yml
+  artifacts:
+    paths:
+      - generated-config.yml

-子流水线：
-  阶段：测试
-  扳机：
-    包括：
-      -  `artifacts`：生成的 config.yml
-        工作：生成配置
-``
+child-pipeline:
+  stage: test
+  trigger:
+    include:
+      - artifact: generated-config.yml
+        job: generate-config
+```

-`generated-config.yml` 从 `artifacts`中提取并用作配置
-用于触发子流水线。
+`generated-config.yml` 是从 `artifacts` 中提取出来的，并被用作触发子流水线的配置。

 ##### 使用来自另一个项目的文件触发子流水线

-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/205157) 在 GitLab 13.5 中。
-
-使用来自同一私有项目的文件触发子流水线
-GitLab 实例，使用 [`include:file`](#includefile)：
+使用来自同一私有项目的文件触发子流水线实例，使用 [`include:file`](#includefile)：

 ```yaml
-子流水线：
-  扳机：
-    包括：
-      - 项目：'我的组/我的流水线库'
-        参考：'主要'
-        文件：'/path/to/child-pipeline.yml'
-``
+child-pipeline:
+  trigger:
+    include:
+      - project: 'my-group/my-pipeline-library'
+        ref: 'main'
+        file: '/path/to/child-pipeline.yml'
+```

-#### 使用 `trigger:strategy` 链接流水线
+#### 使用 `trigger:strategy` 链接流水线[]((#linking-pipelines-with-triggerstrategy))

-默认情况下，`trigger` 流水线任务以 `success` 状态完成
-一旦创建了下游流水线。
+默认情况下，一旦创建了下游流水线，`trigger` 流水线任务就会以 `success` 状态完成。

-要强制 `trigger` 流水线任务等待下游（多项目或子）流水线完成，请使用
-`策略：依赖`。此设置使触发流水线任务以“正在运行”状态等待，直到触发
-流水线完成。此时，`trigger` 流水线任务完成并显示与
-下游流水线任务。
+要强制 `trigger` 流水线任务等待下游（多项目或子）流水线完成，请配置 `strategy: depend`。此设置使触发流水线任务以 `running` 状态等待，直到触发流水线完成。此时，`trigger` 流水线任务与下游流水线任务完成并显示。

-此设置有助于保持流水线执行的线性。在以下示例中，流水线任务来自
-后续阶段等待触发的流水线成功完成之前
-开始，这减少了并行化。
+此设置有助于保持流水线的线性执行。在以下示例中，来自后续阶段的流水线任务在开始之前会等待触发的流水线成功完成，这样做可以减少并行化。

 ```yaml
 trigger_job:
-  扳机：
-    包括：path/to/child-pipeline.yml
-    策略：依赖
-``
-
-#### 通过 API 调用触发流水线
+  trigger:
+    include: path/to/child-pipeline.yml
+    strategy: depend
+```

-要强制重建特定分支、标记或提交，你可以使用 API 调用
-带有触发令牌。

-触发标记不同于 [`trigger`](#trigger) 关键字。
+#### 通过 API 调用触发流水线

-[在触发器文档中阅读更多内容。](../triggers/README.md)
+要强制重建特定分支、 tag 或提交，你可以使用触发 `token` 调用 API 。

-###`可中断`
+触发 `token` 不同于 [`trigger`](#trigger) 关键字。

-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/32022) 在 GitLab 12.3 中。
+### `interruptible`[](#interruptible)

-使用 `interruptible` 表示如果新的流水线运行变得多余，则应取消正在运行的流水线任务。
-默认为`false`（不可中断）。尚未开始（待处理）的流水线任务被认为是可中断的
-并且可以安全取消。
-此值仅在 [自动取消冗余流水线功能](../pipelines/settings.md#auto-cancel-redundant-pipelines) 时使用
-已启用。
+`interruptible` 表示如果新的流水线运行变得多余，则应取消正在运行的流水线任务。默认为`false`（不可中断）。尚未开始（`pending`）的流水线任务被认为是可中断的并且可以安全的取消。此值仅在 [自动取消冗余流水线功能](/docs/ci/pipelines/settings#auto-cancel-redundant-pipelines)启用时可用。

 启用后，如果以下任一情况为真，则在同一分支上启动新流水线时会立即取消流水线：

 - 流水线中的所有流水线任务都设置为可中断的。
- 任何不间断的工作尚未开始。
+- 任何不间断的流水线任务尚未开始。

 将流水线任务设置为可以在启动后安全取消的可中断流水线任务（例如，构建流水线任务）。

 在以下示例中，新流水线运行会导致现有运行流水线变为：

- 取消，如果只有 `step-1` 正在运行或未决。
+- 取消，如果只有 `step-1` 正在运行或 pending。
 - 不会取消，一旦 `step-2` 开始运行。

 不间断流水线任务开始运行后，流水线无法取消。

 ```yaml
-阶段：
-  - 阶段1
-  - 阶段2
-  - 第三阶段
-
-步骤1：
-  阶段：stage1
-  脚本：
-    - echo "可以取消。"
-  可中断：真
+stages:
+  - stage1
+  - stage2
+  - stage3

-第2步：
-  阶段：阶段2
-  脚本：
-    - echo "不能取消。"
+step-1:
+  stage: stage1
+  script:
+    - echo "Can be canceled."
+  interruptible: true

-第 3 步：
-  阶段：stage3
-  脚本：
-    - echo "因为第 2 步不能取消，所以这一步永远不能取消，即使它被设置为可中断。"
-  可中断：真
-``
+step-2:
+  stage: stage2
+  script:
+    - echo "Can not be canceled."

-###`resource_group`
+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
+```

-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/15536) 在 GitLab 12.7 中。
+### `resource_group`[](#resource_group)

-有时在一个环境中同时运行多个流水线任务或流水线
-可能会导致部署过程中出现错误。
+有时在一个环境中同时运行多个流水线任务或流水线可能会导致部署过程中出现错误。

-为避免这些错误，请使用 `resource_group` 属性来确保
-跑步者不会同时运行某些流水线任务。资源组的行为相似
-到其他编程语言中的信号量。
+为避免这些错误，请使用 `resource_group` 属性来确保 Runner 不会同时运行某些流水线任务。资源组的行为与其他编程语言中的信号量极为相似。

-当在 `.codechina-ci.yml` 文件中为流水线任务定义了 `resource_group` 关键字时，
-同一项目的不同流水线中的流水线任务执行是相互排斥的。
-如果属于同一资源组的多个流水线任务同时入队，
-跑步者只选择其中一项工作。其他工作等到
-`resource_group` 是免费的。
+当在 `.codechina-ci.yml` 文件中为流水线任务定义了 `resource_group` 关键字时，同一项目的不同流水线中的流水线任务执行是相互排斥的。如果属于同一资源组的多个流水线任务同时进入队列，Runner 只选择其中一项流水线任务并运行。其他流水线任务需要等到 `resource_group` 空闲后才开始运行。

 例如：

 ```yaml
-部署到生产：
-  脚本：部署
-  资源组：生产
-``
-
-在这种情况下，两个独立流水线中的两个“部署到生产”流水线任务永远不能同时运行。因此，
-你可以确保并发部署永远不会发生在生产环境中。
+deploy-to-production:
+  script: deploy
+  resource_group: production
+```

-你可以为每个环境定义多个资源组。例如，
-部署到物理设备时，你可能有多个物理设备。每台设备
-可以部署到，但在任何给定时间每个设备只能有一个部署。
+在这种情况下，两个独立流水线中的 `deploy-to-production` 流水线任务永远不能同时运行。因此，你可以确保在生产环境中永远不会发生并发部署。

-`resource_group` 值只能包含字母、数字、`-`、`_`、`/`、`$`、`{`、`}`、`.` 和空格。
-它不能以`/`开头或结尾。
+你可以为每个环境定义多个资源组。例如，部署到物理设备时，你可能有多个物理设备。可以部署到每台设备，但在任何给定时间内每个设备只能有一个部署。

-有关更多信息，请参阅 [部署安全](../environments/deployment_safety.md)。
+`resource_group` 值只能包含字母、数字、`-`、`_`、`/`、`$`、`{`、`}`、`.` 和空格。它不能以`/`开头或结尾。

 #### 具有跨项目/父子流水线的流水线级并发控制

-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/39057) 在 GitLab 13.9 中。
-
-你可以为对并发敏感的下游流水线定义`resource_group`
-处决。[`trigger` 关键字](#trigger) 可以触发下游流水线。这
-[`resource_group` 关键字](#resource_group) 可以与它共存。这有助于控制
-部署流水线的并发性，同时运行非敏感流水线任务。
+你可以为对并发敏感的下游流水线定义`resource_group`。[`trigger` 关键字](#trigger) 可以触发下游流水线。[`resource_group` 关键字](#resource_group) 可以与它共存。这有助于控制部署流水线的并发性，同时运行非敏感的流水线任务。

-以下示例在一个项目中有两个流水线配置。当流水线开始运行时，
-非敏感流水线任务首先执行，不受其他并发执行的影响
-流水线。但是，GitLab 确保之前没有其他部署流水线在运行
-触发部署（子）流水线。如果其他部署流水线正在运行，GitLab 等待
-直到这些流水线完成，然后再运行另一个。
+以下示例在一个项目中有两个流水线配置。当流水线开始运行时，非敏感流水线任务首先执行，不受其他并发执行的流水线影响。但是，在这之前系统会确保没有其他部署流水线在运行触发部署（子）流水线。如果其他部署流水线正在运行，系统会等到这些流水线完成，然后再运行另一个。

 ```yaml
-# .codechina-ci.yml（父流水线）
+# .codechina-ci.yml (parent pipeline)

-建造：
-  阶段：构建
-  脚本：回声“建筑...”
+build:
+  stage: build
+  script: echo "Building..."

-测试：
-  阶段：测试
-  脚本：回声“测试...”
+test:
+  stage: test
+  script: echo "Testing..."

-部署：
-  阶段：部署
-  扳机：
-    包括：deploy.codechina-ci.yml
-    策略：依赖
-  资源组：AWS 生产
-``
+deploy:
+  stage: deploy
+  trigger:
+    include: deploy.gitlab-ci.yml
+    strategy: depend
+  resource_group: AWS-production
+```

 ```yaml
-# deploy.codechina-ci.yml（子流水线）
-
-阶段：
-  - 条款
-  - 部署
+# deploy.codechina-ci.yml (child pipeline)

-条款：
-  阶段：准备
-  脚本：回声“供应...”
+stages:
+  - provision
+  - deploy

-部署：
-  阶段：部署
-  脚本：echo“正在部署...”
-``
+provision:
+  stage: provision
+  script: echo "Provisioning..."

-你必须定义 [`strategy:depend`](#linking-pipelines-with-triggerstrategy)
-使用`trigger` 关键字。这确保在下游流水线之前不会释放锁
-完成。
+deployment:
+  stage: deploy
+  script: echo "Deploying..."
+```

-###`发布`
+你必须使用`trigger` 关键字定义 [`strategy:depend`](#linking-pipelines-with-triggerstrategy)。这将确保在下游流水线完成之前不会释放锁。

-> [介绍](https://gitlab.com/gitlab-org/gitlab/merge_requests/19298) 在 GitLab 13.2 中。
+### `release`[](#release)

-使用 `release` 创建一个 [release](../../user/project/releases/index.md)。
-需要 [`release-cli`](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs)
-在你的 GitLab Runner Docker 或 shell 执行器中可用。
+使用 `release` 创建一个 [release](/docs/user/project/releases)。需要 [`release-cli`](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs)
+在你的 Runner Docker 或 shell 执行器中可用。

-支持这些关键字：
+`release` 支持以下这些关键字：

 - [`tag_name`](#releasetag_name)
- [`描述`](#releasedescription)
- [`name`](#releasename)（可选）
- [`ref`](#releaseref)（可选）
- [`里程碑`](#releasemilestones)（可选）
- [`released_at`](#releasereleased_at)（可选）
- [`assets:links`](#releaseassetslinks)（可选）
+- [`description`](#releasedescription)
+- [`name`](#releasename) (可选)
+- [`ref`](#releaseref)  (可选)
+- [`milestones`](#releasemilestones) (可选)
+- [`released_at`](#releasereleased_at) (可选)
+- [`assets:links`](#releaseassetslinks) (可选)

-仅当流水线任务处理没有错误时才会创建发布。如果 Rails API
-在发布创建期间返回错误，`release` 流水线任务失败。
+仅当流水线任务处理没有错误时才会创建 release。如果 Rails API在 release 创建期间返回错误，则 `release` 流水线任务失败。

 #### `release-cli` Docker 镜像

 你必须指定用于 `release-cli` 的 Docker 镜像：

 ```yaml
-图片：registry.gitlab.com/gitlab-org/release-cli:latest
-``
+image：registry.gitlab.com/gitlab-org/release-cli:latest
+```

 #### shell 执行程序的`release-cli`

-> [介绍](https://gitlab.com/gitlab-org/release-cli/-/issues/21) 在 GitLab 13.8 中。
-
-对于 GitLab Runner shell 执行程序，你可以为你的 [支持的操作系统和架构] (https://release-cli-downloads.s3.amazonaws.com/latest/index.html) 手动下载并安装 `release-cli`。
-安装后，你应该可以使用`release` 关键字。
+对于 Runner shell 执行程序，你可以为你的 [支持的操作系统和架构] (https://release-cli-downloads.s3.amazonaws.com/latest/index.html) 手动下载并安装 `release-cli`，安装后完成后就可以使用`release` 关键字了。

 **在 Unix/Linux 上安装**

 1. 下载适用于你系统的二进制文件，以下示例适用于 amd64 系统：

-  ```壳
+  ```shell
  curl --location --output /usr/local/bin/release-cli "https://release-cli-downloads.s3.amazonaws.com/latest/release-cli-linux-amd64"
-  ``
+  ```

 1. 赋予其执行权限：

-  ```壳
-  须藤 chmod +x /usr/local/bin/release-cli
-  ``
+  ```shell
+  sudo chmod +x /usr/local/bin/release-cli
+  ```

-1. 验证`release-cli` 是否可用：
+1. 验证 `release-cli` 是否可用：

-  ```壳
+  ```shell
  $ release-cli -v

-  发布 cli 版本 0.6.0
-  ``
+  release-cli version 0.6.0
+  ```

 **在 Windows PowerShell 上安装**

-1. 在你系统的某处创建一个文件夹，例如`C:\GitLab\Release-CLI\bin`
+1. 在你系统的某处创建一个文件夹，例如`C:\CSDN\Release-CLI\bin`

-  ```壳
-  New-Item -Path 'C:\GitLab\Release-CLI\bin' -ItemType 目录
-  ``
+  ```shell
+  New-Item -Path 'C:\CSDN\Release-CLI\bin' -ItemType Directory
+  ```

 1.下载可执行文件：

-  ```壳
-  PS C:\> Invoke-WebRequest -Uri "https://release-cli-downloads.s3.amazonaws.com/latest/release-cli-windows-amd64.exe" -OutFile "C:\GitLab\Release-CLI \bin\release-cli.exe”
+  ```shell
+  PS C:\> Invoke-WebRequest -Uri "https://release-cli-downloads.s3.amazonaws.com/latest/release-cli-windows-amd64.exe" -OutFile "C:\CSDN\Release-CLI\bin\release-cli.exe"

-      目录：C:\GitLab\Release-CLI
-  模式 LastWriteTime 长度 名称
-  ---- ------------- ------ ----
-  d----- 3/16/2021 4:17 AM
+      Directory: C:\CSDN\Release-CLI
+  Mode                LastWriteTime         Length Name
+  ----                -------------         ------ ----
+  d-----        3/16/2021   4:17 AM                bin

-  ``
+  ```

-1. 将目录添加到你的 `$env:PATH`：
+1. 将目录添加到你的环境变量 `$env:PATH` 中：

-  ```壳
+  ```shell
  $env:PATH += ";C:\GitLab\Release-CLI\bin"
-  ``
+  ```

 1. 验证`release-cli` 是否可用：

-  ```壳
+  ```shell
  PS C:\> release-cli -v

-  发布 cli 版本 0.6.0
-  ``
+  release-cli version 0.6.0
+  ```

-#### 使用自定义 SSL CA 证书颁发机构
+#### 使用自定义 SSL CA 证书

-你可以使用 `ADDITIONAL_CA_CERT_BUNDLE` CI/CD 变量来配置自定义 SSL CA 证书颁发机构，
-当`release-cli`使用带有自定义证书的HTTPS通过API创建发布时，它用于验证对等点。
-`ADDITIONAL_CA_CERT_BUNDLE` 值应包含
-[X.509 PEM 公钥证书的文本表示](https://tools.ietf.org/html/rfc7468#section-5.1)
-或包含证书颁发机构的`path/to/file`。
-例如，要在 `.codechina-ci.yml` 文件中配置此值，请使用以下命令：
+当 `release-cli` 使用带有自定义证书的 HTTPS 请求通过API 创建 release 时，你可以使用 `ADDITIONAL_CA_CERT_BUNDLE` CI/CD 变量来配置自定义 SSL CA 证书并将它用于验证。`ADDITIONAL_CA_CERT_BUNDLE` 值应包含[text representation of the X.509 PEM public-key certificate](https://tools.ietf.org/html/rfc7468#section-5.1)或包含证书颁发机构的 `path/to/file`。例如，要在 `.codechina-ci.yml` 文件中配置此值，请使用以下命令：

 ```yaml
-释放：
-  变量：
+release:
+  variables:
    ADDITIONAL_CA_CERT_BUNDLE: |
-        -----开始认证-----
+        -----BEGIN CERTIFICATE-----
        MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
        ...
-        jWgmPqF3vUbZE0EySetPJquRFRKIesyJuBFMAs=
-        -----结束证书-----
-  脚本：
-    - 回声“创建发布”
-  释放：
-    名称：'我很棒的版本'
+        jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
+        -----END CERTIFICATE-----
+  script:
+    - echo "Create release"
+  release:
+    name: 'My awesome release'
    tag_name: '$CI_COMMIT_TAG'
-``
+```

-`ADDITIONAL_CA_CERT_BUNDLE` 值也可以配置为
-[UI 中的自定义变量](../variables/README.md#custom-cicd-variables),
-要么作为一个`file`，它需要证书的路径，或者作为一个变量，
-这需要证书的文本表示。
+`ADDITIONAL_CA_CERT_BUNDLE` 值也可以配置为[UI 中的自定义变量](/docs/ci/variables#custom-cicd-variables)，
+要么是一个 `file`，它需要证书的路径；要么是一个变量，它需要证书的文本内容。

-####`脚本`
+#### `script`

-除 [trigger](#trigger) 流水线任务之外的所有流水线任务都必须具有 `script` 关键字。一个`发布`
-流水线任务可以使用脚本命令的输出，但如果出现以下情况，你可以使用占位符脚本
-不需要脚本：
+除 [trigger](#trigger) 流水线任务之外的所有流水线任务都必须具有 `script` 关键字。一个 `release`流水线任务可以使用脚本命令的输出，但在你不需要的时候你也可以使用占位符脚本：

 ```yaml
-脚本：
-  - echo '发布工作'
-``
-
-[问题](https://gitlab.com/gitlab-org/gitlab/-/issues/223856) 存在以在即将发布的 GitLab 版本中删除此要求。
+script:
+  - echo 'release job'
+```

-一个流水线可以有多个“发布”流水线任务，例如：
+一个流水线可以有多个 `release` 流水线任务，例如：

 ```yaml
-ios-发布：
-  脚本：
-    - echo 'iOS 发布工作'
-  释放：
-    标签名称：v1.0.0-ios
-    描述：'iOS 发布 v1.0.0'
+ios-release:
+  script:
+    - echo 'iOS release job'
+  release:
+    tag_name: v1.0.0-ios
+    description: 'iOS release v1.0.0'

-安卓发布：
-  脚本：
-    - echo 'Android 发布工作'
-  释放：
-    标签名称：v1.0.0-android
-    描述：'Android 发布 v1.0.0'
-``
+android-release:
+  script:
+    - echo 'Android release job'
+  release:
+    tag_name: v1.0.0-android
+    description: 'Android release v1.0.0'
+```

-####`release:tag_name`
+#### `release:tag_name`

-你必须为发布指定一个 `tag_name`。该标签可以引用现有的 Git 标签或
-你可以指定一个新标签。
+你必须为 release 指定一个 `tag_name`。该 tag 可以引用现有的 Git tag 或者你可以指定一个新的 tag。

-当存储库中不存在指定的标签时，将从流水线的关联 SHA 创建一个新标签。
+当存储库中不存在指定的 tag 时，将从流水线的关联 SHA 创建一个新的 tag。

-例如，从 Git 标签创建发布时：
+例如，从 Git tag 创建发布时：

 ```yaml
-工作：
-  释放：
-    标签名称：$CI_COMMIT_TAG
-    description: '发布说明'
-``
+job:
+  release:
+    tag_name: $CI_COMMIT_TAG
+    description: 'Release description'
+```

-也可以创建任何唯一的标签，在这种情况下，`only: tags` 不是强制性的。
-语义版本控制示例：
+也可以创建任何唯一的标签，在这种情况下，`only: tags` 不是强制性的。比如下方的示例：

 ```yaml
-工作：
-  释放：
-    标签名称：${MAJOR}_${MINOR}_${REVISION}
-    description: '发布说明'
-``
+job:
+  release:
+    tag_name: ${MAJOR}_${MINOR}_${REVISION}
+    description: 'Release description'
+```

 - 只有当流水线任务的主脚本成功时才会创建发布。
 - 如果发布已经存在，则不会更新并且带有`release` 关键字的流水线任务失败。
- `release` 部分在 `script` 标签之后和 `after_script` 之前执行。
+- `release` 在 `script` 之后、 `after_script` 之前执行。

-####`发布：名称`
+#### `release:name`

 版本名称。如果省略，则使用 `release: tag_name` 的值填充。

-####`发布：描述`
-
-指定发布的详细描述。你还可以指定一个包含
-描述。
+#### `release:description`

-##### 从文件中读取描述
+指定发布的详细描述。你还可以指定一个包含描述内容的文件。

-> [介绍](https://gitlab.com/gitlab-org/release-cli/-/merge_requests/67) 在 GitLab 13.7 中。
+##### Read description from a file

-你可以在 `$CI_PROJECT_DIR` 中指定一个包含描述的文件。该文件必须是相对的
-到项目目录（`$CI_PROJECT_DIR`），如果文件是一个符号链接，它就不能驻留
-在 `$CI_PROJECT_DIR` 之外。`./path/to/file` 和文件名不能包含空格。
+你可以在 `$CI_PROJECT_DIR` 中指定一个包含描述的文件。该文件路径必须是相对于项目目录（`$CI_PROJECT_DIR`）的，如果文件是一个符号链接，它就不能驻留在 `$CI_PROJECT_DIR` 之外。`./path/to/file` 和文件名不能包含空格。

 ```yaml
-工作：
-  释放：
-    标签名称：${MAJOR}_${MINOR}_${REVISION}
-    描述：'./path/to/CHANGELOG.md'
-``
+job:
+  release:
+    tag_name: ${MAJOR}_${MINOR}_${REVISION}
+    description: './path/to/CHANGELOG.md'
+```

-####`发布：参考`
+#### `release:ref`

-如果 `release: tag_name` 还不存在，则从 `ref` 创建发布。
-`ref` 可以是提交 SHA、另一个标签名称或分支名称。
+如果 `release: tag_name` 还不存在，则从 `ref` 创建 release。`ref` 可以是提交 SHA、另一个 tag 名称或分支名称。

-####`发布：里程碑`
+#### `release:milestones`

-与发布相关的每个里程碑的标题。
+与 release 相关的每个里程碑的标题。

-####`release:released_at`
+#### `release:released_at`

-发布准备就绪的日期和时间。如果不是，则默认为当前日期和时间
-定义。应该用引号引起来并以 ISO 8601 格式表示。
+release 准备就绪的日期和时间。如果未定义的话则默认使用当前日期和时间。应该用引号引起来并用符合 ISO 8601 格式来表示。

 ```json
-发布时间：'2021-03-15T08:00:00Z'
-``
-
-####`发布：资产：链接`
+released_at: '2021-03-15T08:00:00Z'
+```

-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/271454) 在 GitLab 13.12 中。
+#### `release:assets:links`

-在发布中包含 [资产链接](../../user/project/releases/index.md#release-assets)。
+在发布中包含[资产链接](/docs/user/project/releases#release-assets)。

-笔记：
-需要 `release-cli` 版本 v0.4.0 或更高版本。
+> 注意：需要 `release-cli` 版本 v0.4.0 或更高版本。

 ```yaml
-资产：
-  链接：
-    - 名称：'资产1'
-      网址：'https://example.com/assets/1'
-    - 名称：'资产2'
-      网址：'https://example.com/assets/2'
-      文件路径：'/pretty/url/1' # 可选
-      link_type: 'other' # 可选
-``
+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
+```

 #### `release` 的完整示例

-如果你结合之前的 `release` 例子，你会得到两个选项，这取决于你如何生成
-标签。你不能同时使用这些选项，因此请选择一个：
+如果你结合之前的 `release` 例子，你会得到两个选项，这取决于你如何生成 tag 。你不能同时使用这些选项，因此请选择一个来使用：

- 在推送 Git 标签或添加 Git 标签时创建发布
-  通过转到 **Repository > Tags** 在 UI 中：
+- 在推送 Git tag 或添加 Git tag 时创建 release ：

  ```yaml
-  发布工作：
-    阶段：发布
-    图片：registry.gitlab.com/gitlab-org/release-cli:latest
-    规则：
-      - if: $CI_COMMIT_TAG # 手动创建标签时运行此流水线任务
-    脚本：
-      - echo '正在运行 release_job'
-    释放：
-      name: '发布 $CI_COMMIT_TAG'
-      描述：'使用 release-cli $EXTRA_DESCRIPTION 创建' # $EXTRA_DESCRIPTION 必须被定义
-      tag_name: '$CI_COMMIT_TAG' # 流水线中的其他地方。
-      参考：'$CI_COMMIT_TAG'
-      里程碑：
+  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 release_job'
+    release:
+      name: 'Release $CI_COMMIT_TAG'
+      description: 'Created using the release-cli $EXTRA_DESCRIPTION'  # $EXTRA_DESCRIPTION must be defined
+      tag_name: '$CI_COMMIT_TAG'                                       # elsewhere in the pipeline.
+      ref: '$CI_COMMIT_TAG'
+      milestones:
        - 'm1'
        - 'm2'
        - 'm3'
-      released_at: '2020-07-15T08:00:00Z' # 可选，如果未定义则自动生成，或者可以使用变量。
-      assets: # 可选，多个资产链接
-        链接：
-          - 名称：'资产1'
-            网址：'https://example.com/assets/1'
-          - 名称：'资产2'
-            网址：'https://example.com/assets/2'
-            文件路径：'/pretty/url/1' # 可选
-            link_type: 'other' # 可选
-  ``
-
- 要在提交推送或合并到默认分支时自动创建发布，
-  使用一个用变量定义的新 Git 标签：
-
-  笔记：
-  在 `before_script` 或 `script` 中设置的环境变量不可用于扩展
-  在同一份工作中。阅读更多关于
-  [可能使变量可用于扩展](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6400)。
+      released_at: '2021-05-29T14:05:00Z'  # Optional, is auto generated if not defined, or can use a variable.
+      assets: # Optional, multiple asset links
+        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
+  ```

+- 要在提交推送至默认分支或合并到默认分支时自动创建 release，使用一个用变量定义的新 Git tag：
+
+  > 注意：在 `before_script` 或 `script` 中设置的环境变量不可扩展到同一份流水线任务中使用。
+  
  ```yaml
-  准备工作：
-    stage: prepare # 这个阶段必须在发布阶段之前运行
-    规则：
-      - 如果：$CI_COMMIT_TAG
-        when: never # 手动创建标签时不要运行此流水线任务
-      - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 当提交被推送或合并到默认分支时运行这个流水线任务
-    脚本：
-      - echo "EXTRA_DESCRIPTION=some message" >> variables.env # 生成 EXTRA_DESCRIPTION 和 TAG 环境变量
-      - echo "TAG=v$(cat VERSION)" >> variables.env # 并附加到 variables.env 文件
-    文物：
-      报告：
-        dotenv: variables.env # 使用 artifacts:reports:dotenv 将变量暴露给其他流水线任务
-
-  发布工作：
-    阶段：发布
-    图片：registry.gitlab.com/gitlab-org/release-cli:latest
-    需要：
-      - 工作：prepare_job
-        文物：真实
-    规则：
-      - 如果：$CI_COMMIT_TAG
-        when: never # 手动创建标签时不要运行此流水线任务
-      - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 当提交被推送或合并到默认分支时运行这个流水线任务
-    脚本：
-      - echo '为 $TAG 运行 release_job'
-    释放：
-      name: '发布 $TAG'
-      描述：“使用 release-cli $EXTRA_DESCRIPTION 创建”# $EXTRA_DESCRIPTION 和 $TAG
-      tag_name: '$TAG' # 变量必须在别处定义
-      ref: '$CI_COMMIT_SHA' # 在流水线中。例如，在
-      里程碑：# prepare_job
+  prepare_job:
+    stage: prepare                                              # This stage must run before the release stage
+    rules:
+      - if: $CI_COMMIT_TAG
+        when: never                                             # Do not run this job when a tag is created manually
+      - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH             # Run this job when commits are pushed or merged to the default branch
+    script:
+      - echo "EXTRA_DESCRIPTION=some message" >> variables.env  # Generate the EXTRA_DESCRIPTION and TAG environment variables
+      - echo "TAG=v$(cat VERSION)" >> variables.env             # and append to the variables.env file
+    artifacts:
+      reports:
+        dotenv: variables.env                                   # Use artifacts:reports:dotenv to expose the variables to other jobs
+
+  release_job:
+    stage: release
+    image: registry.gitlab.com/gitlab-org/release-cli:latest
+    needs:
+      - job: prepare_job
+        artifacts: true
+    rules:
+      - if: $CI_COMMIT_TAG
+        when: never                                  # Do not run this job when a tag is created manually
+      - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  # Run this job when commits are pushed or merged to the default branch
+    script:
+      - echo 'running release_job for $TAG'
+    release:
+      name: 'Release $TAG'
+      description: 'Created using the release-cli $EXTRA_DESCRIPTION'  # $EXTRA_DESCRIPTION and the $TAG
+      tag_name: '$TAG'                                                 # variables must be defined elsewhere
+      ref: '$CI_COMMIT_SHA'                                            # in the pipeline. For example, in the
+      milestones:                                                      # prepare_job
        - 'm1'
        - 'm2'
        - 'm3'
-      released_at: '2020-07-15T08:00:00Z' # 可选，如果未定义则自动生成，或者可以使用变量。
-      资产：
-        链接：
-          - 名称：'资产1'
-            网址：'https://example.com/assets/1'
-          - 名称：'资产2'
-            网址：'https://example.com/assets/2'
-            文件路径：'/pretty/url/1' # 可选
-            link_type: 'other' # 可选
-  ``
+      released_at: '2021-05-29T14:05:00Z'  # Optional, is auto generated if not defined, or can use a variable.
+      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
+  ```

 #### 将资产发布为通用包

-你可以使用 [通用包](../../user/packages/generic_packages/) 来托管你的发布资产。
-一个完整的例子，请参见 [Release assets as Generic packages](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs/examples/release-assets-as-generic-package /)
-项目。
+你可以使用通用包来托管你的发布资产。

 #### `release-cli` 命令行

-`release` 节点下的条目被转换为 `bash` 命令行并发送
-到 Docker 容器，其中包含 [release-cli](https://gitlab.com/gitlab-org/release-cli)。
-你也可以直接从 `script` 条目调用 `release-cli`。
+`release` 节点下的条目被转换为 `bash` 命令行并发送到包含了 [release-cli](https://gitlab.com/gitlab-org/release-cli)的 Docker 容器，你也可以直接从 `script` 条目调用 `release-cli`。

-例如，如果你使用前面描述的 YAML：
+例如，如果你使用上方例子中的 YAML：

-```壳
-release-cli create --name "Release $CI_COMMIT_SHA" --description "使用 release-cli $EXTRA_DESCRIPTION 创建" --tag-name "v${MAJOR}.${MINOR}.${REVISION}" --ref "$CI_COMMIT_SHA" --released-at "2020-07-15T08:00:00Z" --milestone "m1" --milestone "m2" --milestone "m3" --assets-link "{\"name\" :\"asset1\",\"url\":\"https://example.com/assets/1\",\"link_type\":\"other\"}
-``
-
-###`秘密`
-
-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33014) 在 GitLab 13.4 中。
-
-使用 `secrets` 指定流水线任务需要的 [CI/CD Secrets](../secrets/index.md)。它应该是一个哈希，
-键应该是可供流水线任务使用的变量的名称。
-每个秘密的值都保存在一个临时文件中。这个文件的路径存储在这些
-变量。
-
-#### `secrets:vault` **(PREMIUM)**
-
-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/28321) 在 GitLab 13.4 中。
-
-使用 `vault` 指定 [Hashicorp's Vault](https://www.vaultproject.io/) 提供的机密。
-
-这种语法有多种形式。最短的形式假定使用
-[KV-V2](https://www.vaultproject.io/docs/secrets/kv/kv-v2) 秘密引擎，
-安装在默认路径 `kv-v2` 上。秘密路径的最后一部分是
-字段来获取值：
-
-```yaml
-工作：
-  秘密：
-    数据库密码：
-      vault: production/db/password # 转换为秘密 `kv-v2/data/production/db`，字段 `password`
-``
-
-你可以通过添加以 `@` 开头的后缀来指定自定义机密引擎路径：
-
-```yaml
-工作：
-  秘密：
-    数据库密码：
-      vault: production/db/password@ops # 转换为秘密 `ops/data/production/db`，字段 `password`
-``
+```shell
+release-cli create --name "Release $CI_COMMIT_SHA" --description "Created using the release-cli $EXTRA_DESCRIPTION" --tag-name "v${MAJOR}.${MINOR}.${REVISION}" --ref "$CI_COMMIT_SHA" --released-at "2020-07-15T08:00:00Z" --milestone "m1" --milestone "m2" --milestone "m3" --assets-link "{\"name\":\"asset1\",\"url\":\"https://example.com/assets/1\",\"link_type\":\"other\"}
+```

-在语法的详细形式中，你可以明确指定所有详细信息：
+### `secrets`[](#secrets)

-```yaml
-工作：
-  秘密：
-    DATABASE_PASSWORD: # 转换为秘密 `ops/data/production/db`，字段 `password`
-      保险库：
-        引擎：
-          名称： kv-v2
-          路径：ops
-        路径：生产/数据库
-        字段：密码
-``
+使用 `secrets` 指定流水线任务需要的 CI/CD Secrets。它应该是一个 hash 值，键应该是可供流水线任务使用的变量的名称。每个秘密的值都保存在一个临时文件中。这个文件的路径存储在这些变量中。

-###`页面`
+### `pages`

-使用 `pages` 将静态内容上传到 GitLab。内容
-然后作为网站发布。你必须：
+使用 `pages` 将静态内容上传到 CODE CHINA 中。内容会作为网站发布。你必须：

 - 将任何静态内容放在 `public/` 目录中。
 - 定义 [`artifacts`](#artifacts) 和 `public/` 目录的路径。

-以下示例将所有文件从项目的根目录移动到
-`public/` 目录。`.public` 解决 `cp` 也不会复制
-`public/` 在无限循环中传递给自身：
+以下示例将所有文件从项目的根目录移动到 `public/` 目录。`.public` 在 `cp` 时将不会复制 `public/`，以避免陷入无限循环：

 ```yaml
-页数：
-  阶段：部署
-  脚本：
+pages:
+  stage: deploy
+  script:
    - mkdir .public
    - cp -r * .public
-    - mv .public 公共
-  文物：
-    路径：
-      - 上市
-  只要：
-    - 主要的
-``
-
-查看 [GitLab Pages 用户文档](../.project/pages/index.md)。
+    - mv .public public
+  artifacts:
+    paths:
+      - public
+  only:
+    - main
+```

-###`继承`
+> 注，目前 CODE CHINA 单独提供了 Pages 服务，不再支持通过 CI YAML 文件触发的 Pages 部署，具体可参考 [Pages 帮助文档](/docs/user/pages)。

-> [介绍](https://gitlab.com/gitlaitlab/-/issues/207484) 在 GitLab 12.9 中。
+### `inherit`[](#inherit)

-使用 `inherit:` 来控制全局定义继承
-和变量。
+使用 `inherit:` 来控制全局定义继承和变量。

-要启用或禁用所有 `default:` 或 `vs:` 关键字的继承，请使用：
+要启用或禁用所有 `default:` 或 `variables:` 关键字的继承，请使用：

- `default: true` 或 `default: fa
- `变量：真`或`变量：假`
+- `default: true` 或 `default: false`
+- `variables: true` 或 `variables: false`

-要仅继承 `default:` 关键字或 `var` 的子集，请指定
-你想继承。任何未列出的都是**不*用
-以下格式之一：
+要仅继承 `default:` 关键字或 `variables:` 的子集，请指定你想继承的内容。任何未列出的内容都**不**会集成。请使用以下格式中的一种：

 ```yaml
-继承：
-  默认值：[关键字 1，关键字 2]
-  变量：[VARIABLE1, VARIABLE2]
-``
+inherit:
+  default: [keyword1, keyword2]
+  variables: [VARIABLE1, VARIABLE2]
+```

 或者：

 ```yaml
-继承：
-  默认：
-    - 关键字 1
-    - 关键字 2
-  变量：
-    - 变量 1
-    - 变量 2
-``
+inherit:
+  default:
+    - keyword1
+    - keyword2
+  variables:
+    - VARIABLE1
+    - VARIABLE2
+```

 在以下示例中：

-`rubocop`：
-  - 继承：没有。
+- `rubocop`：
+  - 继承：没有继承任何内容。
 - `rspec`：
-  - 继承：默认的`image` 和`WEBHOO变量。
-  - **不** 继承：默认的`before_sc和`DOMAIN` 变量。
-`水豚`：
-  - 继承：默认的`before_script` `。
-  - **不** 继承：`DOMAIN` 和`WEBH` 变量。
-`业力`：
-  - 继承：默认的`image` 和`before`，以及`DOMAIN` 变量。
-  - **不** 继承：`WEBHOOK_URL` 
-
-```yaml
-默认：
-  图像：'红宝石：2.4'
-  之前_脚本：
-    - 回声你好世界
-
-变量：
-  域：example.com
-  WEBHOOK_URL: https://my-webhooke.com
-
-防暴警察：
-  继承：
-    默认值：假
-    变量：假
-  脚本：捆绑执行 rubocop
-
-规格：
-  继承：
-    默认值：[图像]
-    变量：[WEBHOOK_URL]
-  脚本：bundle exec rspec
-
-水豚：
-  继承：
-    变量：假
-  脚本：捆绑执行水豚
-
-业力：
-  继承：
-    默认值：真
-    变量：[域]
-  剧本：业力
-``
-
-##`变量`
-
-> 在 GitLab Runner v0.5.0 中引入。
-
-[CI/CD 变量](../variables/README.传递给流水线任务的可配置值。
-它们可以在全局和每个流水线任务中设置。
+  - 继承：默认的 `image` 和 `WEBHOOK_URL` 变量。
+  - **不** 继承：默认的 `before_script` 和 `DOMAIN` 变量。
+- `capybara`：
+  - 继承：默认的 `before_script` 和 `image`。
+  - **不** 继承：`DOMAIN` 和 `WEBHOOK_URL` 变量。
+- `karma`：
+  - 继承：默认的`image` 和 `before_script`，以及 `DOMAIN` 变量。
+  - **不** 继承：`WEBHOOK_URL` 变量。 
+
+```yaml
+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
+```
+
+## `variables`[](#variables)
+
+[CI/CD 变量](/docs/ci/variables)是一些传递给流水线任务的可配置值。它们可以在全局以及每个流水线任务中设置。

 有两种类型的变量。

- [自定义变量](../variables/READMstom-cicd-variables):
-  你可以在 GitLab UI 中的 `.gitlal` 文件中定义它们的值，
-  或通过使用 API。你还可以在 GitL中输入变量
-  [手动运行流水线](../pipelines/indun-a-pipeline-manually)。
- [预定义变量](../variables/predeariables.md):
-  这些值由跑步者自己设置。
-  一个例子是`CI_COMMIT_REF_NAME项目构建的分支或标签。
+- [自定义变量](/docs/ci/variables#custom-cicd-variables):
+  你可以在 CODE CHINA UI 中的 `.codechina-ci.yml` 文件中定义它们的值，或通过 API 来定义。你还可以在[手动运行流水线](/docs/ci/pipelines#run-a-pipeline-manually)中输入变量。
+- 预定义变量：这些值由 Runner 自己设置。比如 `CI_COMMIT_REF_NAME`，它是指构建项目的分支或 tag。

-定义变量后，你可以在所有执行的中使用它。
+定义好变量后，你可以在所有执行的中使用它。

-变量用于非敏感项目配置，例如：
+变量用于非敏感的项目配置，例如：

 ```yaml
-变量：
-  DEPLOY_SITE: "https://example.c
+variables:
+  DEPLOY_SITE: "https://example.com/"

-部署_流水线任务：
-  阶段：部署
-  脚本：
-    - 部署脚本 --url $DEPLOY_SITE "/"
+deploy_job:
+  stage: deploy
+  script:
+    - deploy-script --url $DEPLOY_SITE --path "/"

 deploy_review_job:
-  阶段：部署
-  变量：
+  stage: deploy
+  variables:
    REVIEW_PATH: "/review"
-  脚本：
-    - deploy-review-script --url _SITE --path $REVIEW_PATH
-``
-
-变量的名称和值只能使用整数和字
+  script:
+    - deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
+```

-如果在 `gitlab-ci.yml` 文件的顶个变量，它是全局的，
-这意味着它适用于所有工作。如果定义变量，则它可用
-只到那个工作。
+变量的名称和值只能使用整数和字符。

-如果为特定流水线任务全局定义了同名变
-[特定于流水线任务的变量覆盖全局变量](..les/README.md#cicd-variable-precedence)。
+如果在 `.codechina-ci.yml` 文件的顶部定义了一个变量，那么这个变量就是全局的，这意味着它适用于所有流水线任务。如果是在某个流水线任务重定义的变量，则它只可用于该流水线任务。

-所有 YAML 定义的变量也设置为任何
-[Docker 服务容器](../services/ind
+如果为特定流水线任务定义了与全局变量同名的变量，则[特定于流水线任务的变量将覆盖全局变量](/docs/ci/variables#cicd-variable-precedence)。

-你可以使用 [YAML 变量锚点](#yaml-or-variables)。
+所有 YAML 中定义的变量对关联的 Docker 服务容器同样生效。

-### 在手动流水线中预填充变量
+你可以使用 [YAML 变量锚点](#yaml-anchors-for-variables)。

-> [引入](https://gitlab.com/gitlalab/-/issues/30101) GitLab 13.7。
+### 在手动流水线中预填充变量[]()

-使用 `value` 和 `description` 预先填充的流水线级（全局）变量](../pipelines/index.md#prefill-variables-in-manuapipe
-当[手动运行流水线](../pipelines/ind-a-pipeline-manually)：
+当[手动运行流水线](/docs/ci/pipelines#run-a-pipeline-manually)时可使用 `value` 和 `description` 预先填充的[流水线级（全局）变量](/docs/ci/pipelines#prefill-variables-in-manuapipe)：

 ```yaml
-变量：
-  部署环境：
-    value: "staging" # 默认部署到
-    描述：“部署目标。如果需要，为‘canary’或‘production’。”
-``
+variables:
+  DEPLOY_ENVIRONMENT:
+    value: "staging"  # Deploy to staging by default
+    description: "The deployment target. Change this variable to 'canary' or 'production' if needed."
+```

-当你手动运行流水线时，你无法将作预填充。
+当你手动运行流水线时，你无法将对流水线任务级别的变量进行预填充操作。

-### 使用变量配置跑步者行为
+### 使用变量配置 Runner 行为

-你可以使用 [CI/CD variables](../vREADME.md) 来配置运行程序如何处理 Git 请求：
+你可以使用 [CI/CD variables](/docs/ci/variables) 来配置运行程序如何处理 Git 请求：

- [`GIT_STRATEGY`](../runners/REAt-strategy)
- [`GIT_SUBMODULE_STRATEGY`](../rADME.md#git-submodule-strategy)
- [`GIT_CHECKOUT`](../runners/REAt-checkout)
- [`GIT_CLEAN_FLAGS`](../runners/#git-clean-flags)
- [`GIT_FETCH_EXTRA_FLAGS`](../ruDME.md#git-fetch-extra-flags)
- [`GIT_DEPTH`](../runners/READMEow-cloning)（浅克隆）
- [`GIT_CLONE_PATH`](../runners/Rcustom-build-directories)（自定义构建目录）
- [`TRANSFER_METER_FREQUENCY`](..README.md#artifact-and-cache-settings)（ `artifacts`/缓存表更新频率）
- [`ARTIFACT_COMPRESSION_LEVEL`](s/README.md#artifact-and-cache-settings)（ `artifacts`存档器压缩级别）
- [`CACHE_COMPRESSION_LEVEL`](../EADME.md#artifact-and-cache-settings)（缓存归档压缩级别）
+- [`GIT_STRATEGY`](/docs/ci/runners#git-strategy)
+- [`GIT_SUBMODULE_STRATEGY`](/docs/ci/runners#git-submodule-strategy)
+- [`GIT_CHECKOUT`](/docs/ci/runners#git-checkout)
+- [`GIT_CLEAN_FLAGS`](/docs/ci/runners#git-clean-flags)
+- [`GIT_FETCH_EXTRA_FLAGS`](/docs/ci/runners#git-fetch-extra-flags)
+- [`GIT_DEPTH`](/docs/ci/runners#shallow-cloning)（浅克隆）
+- [`GIT_CLONE_PATH`](#custom-build-directories)（自定义构建目录）
+- [`TRANSFER_METER_FREQUENCY`](/docs/ci/runners#artifact-and-cache-settings)（ `artifacts`/缓存更新频率）
+- [`ARTIFACT_COMPRESSION_LEVEL`](/docs/ci/runners#artifact-and-cache-settings)（ `artifacts`存档器压缩级别）
+- [`CACHE_COMPRESSION_LEVEL`](/docs/ci/runners#artifact-and-cache-settings)（缓存归档压缩级别）

-你还可以使用变量来配置跑步者的次数
-[尝试流水线任务执行的某些阶段](../runne.md#job-stages-attempts)。
+你还可以使用变量来配置 Runner 的次数[尝试流水线任务执行的某些阶段](/docs/ci/runners#job-stages-attempts)。

-## YAML 特定的功能
+## YAML 特定的功能[]()

-在你的 `.codechina-ci.yml` 文件中AML 特定的特性，比如锚点（`&`）、别名（`*`）、
-和地图合并（`<<`）。使用这些功
-`.codechina-ci.yml` 文件中的代码。
+在你的 `.codechina-ci.yml` 文件中，你可以使用一些 YAML 特定的特性，比如锚点（`&`）、别名（`*`）、和 map 合并（`<<`）。使用这些特性可以减少 `.codechina-ci.yml` 文件中的代码复杂性。

-阅读有关各种 [YAML 功能](https://minutes.com/docs/yaml/) 的更多信息。
+点击阅读更多有关各种 [YAML 功能](https://minutes.com/docs/yaml/) 的信息。

-在大多数情况下，[`extends` 关键字s) 对用户更友好，你应该
-尽可能使用它。
+在大多数情况下，[`extends` 关键字](#extends) 对用户更友好，你应该尽可能地使用它。

 你可以使用 YAML 锚点来合并 YAML 。

-### 锚
+### 锚[](#anchors)

-YAML 有一个叫做“锚点”的功能，你制
-整个文档的内容。
+YAML 有一个叫做“锚点”的功能，可以允许你在整个文档中复制内容。

-使用锚点复制或继承属性。将锚点与作](#hide-jobs) 结合使用
-为你的工作提供模板。当有重复的键
-基于键执行反向深度合并。
+使用锚点复制或继承属性。将锚点与[隐藏的流水线任务](#hide-jobs) 结合起来用作你的流水线任务模板。当有重复的键，系统会基于键执行反向深度合并。

-使用 [`include`](#include) 时，文件使用 YAML 锚点
-关键词。锚只在定义它们的文件中置
-从不同的 YAML 文件，使用 [`!refer签](#reference-tags) 或
-[`extends` 关键字](#extends)。
+当使用 [`include`](#include) 时，你将无法跨文件使用 YAML 锚点关键词。锚只在定义它们的文件中生效。如果要在不同的 YAML 文件中重用配置，你可以使用 [`!reference` tags](#reference-tags) 或 [`extends` 关键词](#extends)。

-以下示例使用锚点和地图合并。它，
-`test1` 和 `test2`，继承了 `.job_ 配置，每个
-定义了自己的自定义“脚本”：
+以下示例中，使用锚点和 map 合并。它创建了 `test1` 和 `test2` 两个流水线任务，并继承了 `.job_template` 的配置，每个流水线任务都定义了自己的自定义 `script`：

 ```yaml
-.job_template: &job_configuration # 隐藏的 yaml 配置，它定义了一个名为“job_configuration”的锚点
-  图片：红宝石：2.6
-  服务：
+.job_template: &job_configuration  # Hidden yaml configuration that defines an anchor named 'job_configuration'
+  image: ruby:2.6
+  services:
    - postgres
-    - Redis
+    - redis

-测试1：
-  <<: *job_configuration # 合并'job_configuration'别名的内容
-  脚本：
-    - test1 项目
+test1:
+  <<: *job_configuration           # Merge the contents of the 'job_configuration' alias
+  script:
+    - test1 project

-测试2：
-  <<: *job_configuration # 合并'job_configuration'别名的内容
-  脚本：
-    - 测试2项目
-``
+test2:
+  <<: *job_configuration           # Merge the contents of the 'job_configuration' alias
+  script:
+    - test2 project
+```

-`&` 设置锚点的名称（`job_configuration`），`<<` 表示“合并
-给定散列到当前的散列中，”并且 `*` 包括命名锚
-（再次`job_configuration`）。这个例子的扩展版本是：
+`&` 设置了锚点的名称（`job_configuration`），`<<` 表示“合并给定 hash 到当前的 hash 中，然后 `*` 引用了锚点（还是`job_configuration`）。这个例子的扩展版本是：

 ```yaml
-.job_template：
-  图片：红宝石：2.6
-  服务：
+.job_template:
+  image: ruby:2.6
+  services:
    - postgres
-    - Redis
+    - redis

-测试1：
-  图片：红宝石：2.6
-  服务：
+test1:
+  image: ruby:2.6
+  services:
    - postgres
-    - Redis
-  脚本：
-    - test1 项目
+    - redis
+  script:
+    - test1 project

-测试2：
-  图片：红宝石：2.6
-  服务：
+test2:
+  image: ruby:2.6
+  services:
    - postgres
-    - Redis
-  脚本：
-    - 测试2项目
-``
+    - redis
+  script:
+    - test2 project
+```

-你可以使用锚点来定义两组服务。例如，`test:postgres`
-和 `test:mysql` 共享 `.job_template` 中定义的 `script`，但使用不同的
-`services`，在 `.postgres_services` 和 `.mysql_services` 中定义：
+你可以使用锚点来定义两组不同的服务。例如，`test:postgres`和 `test:mysql` ，他们共享 `.job_template` 中定义的 `script`，但使用不同的 `services`，可以这样定义 `.postgres_services` 和 `.mysql_services` ：

 ```yaml
 .job_template: &job_configuration
-  脚本：
-    - 测试项目
-  标签：
-    - 开发
+  script:
+    - test project
+  tags:
+    - dev

 .postgres_services:
-  服务：&postgres_configuration
+  services: &postgres_configuration
    - postgres
-    - 红宝石
+    - ruby

 .mysql_services:
-  服务：&mysql_configuration
+  services: &mysql_configuration
    - mysql
-    - 红宝石
+    - ruby

-测试：postgres：
+test:postgres:
  <<: *job_configuration
-  服务：*postgres_configuration
-  标签：
+  services: *postgres_configuration
+  tags:
    - postgres

-测试：mysql：
+test:mysql:
  <<: *job_configuration
-  服务：*mysql_configuration
-``
+  services: *mysql_configuration
+```

-扩展版本是：
+上面这个例子的扩展版本是：

 ```yaml
-.job_template：
-  脚本：
-    - 测试项目
-  标签：
-    - 开发
+.job_template:
+  script:
+    - test project
+  tags:
+    - dev

 .postgres_services:
-  服务：
+  services:
    - postgres
-    - 红宝石
+    - ruby

 .mysql_services:
-  服务：
+  services:
    - mysql
-    - 红宝石
+    - ruby

-测试：postgres：
-  脚本：
-    - 测试项目
-  服务：
+test:postgres:
+  script:
+    - test project
+  services:
    - postgres
-    - 红宝石
-  标签：
+    - ruby
+  tags:
    - postgres

-测试：mysql：
-  脚本：
-    - 测试项目
-  服务：
+test:mysql:
+  script:
+    - test project
+  services:
    - mysql
-    - 红宝石
-  标签：
-    - 开发
-``
-
-你可以看到隐藏的流水线任务可以方便地用作模板，并且
-`tags: [postgres]` 覆盖 `tags: [dev]`。
+    - ruby
+  tags:
+    - dev
+```

-#### 脚本的 YAML 锚点
+你可以看到将隐藏的流水线任务用作模板时使用起来非常方便，并且 `tags: [postgres]` 覆盖 `tags: [dev]`。

-> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/23005) 在 GitLab 12.5 中。
+#### 脚本的 YAML 锚点[](#yaml-anchors-for-variables)

-你可以将 [YAML 锚点](#anchors) 与 [script](#script)、[`before_script`](#before_script)、
-和 [`after_script`](#after_script) 在多个流水线任务中使用预定义的命令：
+你可以在 [script](#script)、[`before_script`](#before_script)、以及 [`after_script`](#after_script) 中使用 [YAML 锚点](#anchors) ，让其在多个流水线任务中使用预定义的命令：

 ```yaml
 .some-script-before: &some-script-before
-  - echo "先执行这个脚本"
+  - echo "Execute this script first"

 .some-script: &some-script
-  - echo "第二次执行这个脚本"
-  - echo "也执行这个脚本"
+  - echo "Execute this script second"
+  - echo "Execute this script too"

 .some-script-after: &some-script-after
-  - echo "最后执行这个脚本"
+  - echo "Execute this script last"

-工作1：
-  之前_脚本：
+job1:
+  before_script:
    - *some-script-before
-  脚本：
-    - *一些脚本
-    - echo "执行某事，仅针对这项工作"
-  后脚本：
+  script:
+    - *some-script
+    - echo "Execute something, for this job only"
+  after_script:
    - *some-script-after

-工作2：
-  脚本：
+job2:
+  script:
    - *some-script-before
-    - *一些脚本
-    - echo "执行其他操作，仅针对此工作"
+    - *some-script
+    - echo "Execute something else, for this job only"
    - *some-script-after
-``
+```

 #### 变量的 YAML 锚点

-使用 [YAML 锚点](#anchors) 和 `variables` 重复赋值
-跨多个流水线任务的变量。你还可以在流水线任务时使用 YAML 锚点
-需要一个特定的 `variables` 块，否则会覆盖全局变量。
+使用 [YAML 锚点](#anchors) 和 `variables` 给跨多个流水线任务的变量重复赋值。当流水线任务需要一个特定的 `variables` 块时，你也可以使用 YAML 锚点，以避免会覆盖全局变量。

-以下示例显示如何在不影响的情况下覆盖 `GIT_STRATEGY` 变量
-`SAMPLE_VARIABLE` 变量的使用：
+以下示例显示如何在不影响 `SAMPLE_VARIABLE` 变量使用的情况下覆盖 `GIT_STRATEGY` 变量：

 ```yaml
-# 全局变量
-变量：&全局变量
-  SAMPLE_VARIABLE：sample_variable_value
-  ANOTHER_SAMPLE_VARIABLE：another_sample_variable_value
+# global variables
+variables: &global-variables
+  SAMPLE_VARIABLE: sample_variable_value
+  ANOTHER_SAMPLE_VARIABLE: another_sample_variable_value

-# 一个必须设置 GIT_STRATEGY 变量但依赖于全局变量的流水线任务
+# a job that must set the GIT_STRATEGY variable, yet depend on global variables
 job_no_git_strategy:
-  阶段：清理
-  变量：
-    <<: *全局变量
-    GIT_STRATEGY：无
-  脚本：echo $SAMPLE_VARIABLE
-``
+  stage: cleanup
+  variables:
+    <<: *global-variables
+    GIT_STRATEGY: none
+  script: echo $SAMPLE_VARIABLE
+```

-### 隐藏工作
+### 隐藏的流水线任务

-如果你想暂时禁用一个流水线任务，而不是注释掉所有的
-定义流水线任务的行：
+如果你想暂时禁用一个流水线任务，并且不希望使用注释掉所有的定义流水线任务的行这种方式：

 ```yaml
-# hidden_job:
-＃ 脚本：
-# - 运行测试
-``
+# hidden_job:
+#   script:
+#     - run test
+```

-相反，你可以用一个点（`.`）开始它的名字，它不会被处理
-亚搏体育应用 CI/CD。在下面的例子中，`.hidden_job` 被忽略：
+这样情况下，你可以用一个点（`.`）开始它的名字，它不会被 CI/CD 处理。在下面的例子中，`.hidden_job` 将被忽略：

 ```yaml
-.hidden_job：
-  脚本：
-    - 运行测试
-``
-
-使用此功能忽略流水线任务，或使用
-[YAML-specific features](#yaml-specific-features) 并转换隐藏流水线任务
-成模板。
+.hidden_job:
+  script:
+    - run test
+```

-### `!reference` 标签
+使用此功能来忽略流水线任务，或使用 YAML-specific 特性功能将隐藏流水线任务转换成模板。

-> - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/266173) 在 GitLab 13.9 中。
+### `!reference` tags

-使用 `!reference` 自定义 YAML 标签从其他流水线任务中选择关键字配置
-部分并在当前部分中重用它。与 [YAML 锚点](#anchors) 不同，你可以
-使用 `!reference` 标签重用 [included](#include) 配置中的配置
-文件也是如此。
+使用 `!reference` 自定义 YAML 标签，可以从其他流水线任务中选择关键字配置部分并在当前部分中重用它。与 [YAML 锚点](#anchors) 不同，你可以使用 `!reference` 标签重用 [included](#include) 配置，包括其中的配置文件也可以重用。

-在以下示例中，来自两个不同位置的 `script` 和一个 `after_script` 是
-在 `test` 流水线任务中重用：
+在以下示例中，来自两个不同位置的 `script` 和 `after_script` 在 `test` 流水线任务中被重用：

- `setup.yml`：
+- `setup.yml`:

  ```yaml
-  。设置：
-    脚本：
-      - echo 创建环境
-  ``
+  .setup:
+    script:
+      - echo creating environment
+  ```

-`.codechina-ci.yml`：
+- `.codechina-ci.yml`:

  ```yaml
-  包括：
-    - 本地：setup.yml
+  include:
+    - local: setup.yml

-  。拆除：
-    后脚本：
-      - echo 删除环境
+  .teardown:
+    after_script:
+      - echo deleting environment

-  测试：
-    脚本：
+  test:
+    script:
      - !reference [.setup, script]
-      - echo 运行我自己的命令
-    后脚本：
+      - echo running my own command
+    after_script:
      - !reference [.teardown, after_script]
-  ``
+  ```

-在下面的例子中，`test-vars-1` 重用了 `.vars` 中的所有变量，而 `test-vars-2`
-选择一个特定的变量并将其作为新的“MY_VAR”变量重用。
+在下面的例子中，`test-vars-1` 重用了 `.vars` 中的所有变量，而 `test-vars-2` 选择一个特定的变量并将其作为新的 `MY_VAR` 变量重用。

 ```yaml
-.vars：
-  变量：
-    网址：“http://my-url.internal”
-    IMPORTANT_VAR：“详细信息”
+.vars:
+  variables:
+    URL: "http://my-url.internal"
+    IMPORTANT_VAR: "the details"

-测试变量-1：
-  变量：!reference [.vars, variables]
-  脚本：
-    - 打印环境
+test-vars-1:
+  variables: !reference [.vars, variables]
+  script:
+    - printenv

-测试变量 2：
-  变量：
+test-vars-2:
+  variables:
    MY_VAR: !reference [.vars, variables, IMPORTANT_VAR]
-  脚本：
-    - 打印环境
-``
+  script:
+    - printenv
+```

-你不能重复使用已经包含 `!reference` 标签的部分。只有一层
-支持嵌套。
+你不能重复使用已经包含 `!reference` 标签的部分。只支持一层嵌套。

 ## 跳过流水线

-要在不触发流水线的情况下推送提交，请添加 `[ci skip]` 或 `[skip ci]`，使用任何
-大写，到你的提交消息。
+要在不触发流水线的情况下推送提交，请在你的提交消息中添加 `[ci skip]` 或 `[skip ci]`，支持大写。

-或者，如果你使用 Git 2.10 或更高版本，请使用 `ci.skip` [Git push option](../../user/project/push_options.md#push-options-for-gitlab-cicd)。
-`ci.skip` 推送选项不会跳过合并请求
-流水线。
+或者，如果你使用 Git 2.10 或更高版本，请使用 `ci.skip` Git push option。`ci.skip` 推送选项不会跳过合并请求流水线。

 ## 处理 Git 推送

-GitLab 在以下情况下最多创建四个分支和标记流水线
-在单个 `git push` 调用中推送多个更改。
+当在单个 `git push` 调用中推送多个更改时，系统将最多创建四个分支流水线或 tag 流水线。

-此限制不会影响任何更新的合并请求流水线。
-所有更新的合并请求都在使用时创建了一个流水线
-[合并请求的流水线](../merge_request_pipelines/index.md)。
+此限制不会影响任何更新的合并请求流水线。所有更新的合并请求在创建时都使用的是合并请求流水线的流水线。

 ## 弃用的关键字

@@ -4264,34 +4007,28 @@ GitLab 在以下情况下最多创建四个分支和标记流水线

 ### 全局定义的`types`

-警告：
-`types` 已弃用，可能会在未来版本中删除。
-使用 [`stages`](#stages) 代替。
+> 警告：`types` 已弃用，可能会在未来版本中删除。请使用 [`stages`](#stages) 代替。

 ### 流水线任务定义的`type`

-警告：
-`type` 已弃用，可能会在未来版本之一中删除。
-使用 [`stage`](#stage) 代替。
+> 警告：`type` 已弃用，可能会在未来的某一版本中删除。请使用 [`stage`](#stage) 代替。

 ### 全局定义的`image`、`services`、`cache`、`before_script`、`after_script`

-定义 `image`、`services`、`cache`、`before_script` 和
-全局不推荐使用 `after_script`。可以删除支持
-从未来的版本。
+不推荐使用全局定义的 `image`、`services`、`cache`、`before_script` 和 `after_script`。可能会在未来版本中删除。

 使用 [`default:`](#custom-default-keyword-values) 代替。例如：

 ```yaml
-默认：
-  图像：红宝石：3.0
-  服务：
-    - 码头工人：dind
-  缓存：
-    路径：[供应商/]
-  之前_脚本：
-    - 捆绑配置设置路径供应商/捆绑
-    - 捆绑安装
-  后脚本：
-    - rm -rf tmp
-```
+default:
+  image: ruby:3.0
+  services:
+    - docker:dind
+  cache:
+    paths: [vendor/]
+  before_script:
+    - bundle config set path vendor/bundle
+    - bundle install
+  after_script:
+    - rm -rf tmp/
+```
\ No newline at end of file