Skip to content

帮助文档
帮助文档

GitCode / 帮助文档

通知 1805
Star 580
Fork 459
帮助文档
帮助文档

yaml · 变更

页面历史
update 编写于 作者: Miykael_xxm's avatar Miykael_xxm
隐藏空白更改
内联 并排
Showing with 1000 addition and 1244 deletion
docs/ci/yaml.md
View page @ 533eea51
...@@ -293,7 +293,7 @@ workflow: ...@@ -293,7 +293,7 @@ workflow:
- 对分支的更改，但该分支的合并请求已打开，请不要运行分支流水线。 - 对分支的更改，但该分支的合并请求已打开，请不要运行分支流水线。
- 对分支的更改，但没有任何打开的合并请求，运行分支流水线。 - 对分支的更改，但没有任何打开的合并请求，运行分支流水线。
您还可以向现有`workflow`部分添加 `rules` ，以便在创建合并请求时从分支流水线切换到合并请求流水线。 你还可以向现有`workflow`部分添加 `rules` ，以便在创建合并请求时从分支流水线切换到合并请求流水线。
将此 `rules` 添加到该`workflow`部分的顶部，然后是已经存在的其他 `rules` ： 将此 `rules` 添加到该`workflow`部分的顶部，然后是已经存在的其他 `rules` ：
...@@ -309,13 +309,13 @@ workflow: ...@@ -309,13 +309,13 @@ workflow:
### `include`[](#include) ### `include`[](#include)
用于`include`在 CI/CD 配置中包含外部 YAML 文件。您可以将一个长的`codechina-ci.yml`文件分解为多个文件以提高可读性，或减少同一配置在多个位置的重复。 用于`include`在 CI/CD 配置中包含外部 YAML 文件。你可以将一个长的`codechina-ci.yml`文件分解为多个文件以提高可读性，或减少同一配置在多个位置的重复。
您还可以将模板文件存储在中央存储库中，并通过`include`将它们存储在项目中。 你还可以将模板文件存储在中央存储库中，并通过`include`将它们存储在项目中。
`include`要求外部 YAML 文件具有扩展名`.yml`或`.yaml`，否则不引用外部文件。 `include`要求外部 YAML 文件具有扩展名`.yml`或`.yaml`，否则不引用外部文件。
您不能在不同 YAML 文件之间通过使用 YAML 锚点的方式来 `include` `.yaml`。您只能引用同一文件中的锚点。要重用来自不同 YAML 文件的配置，请使用[`!reference` 标签](#reference-tags) 或 [`extends` 关键字](#extends)。 你不能在不同 YAML 文件之间通过使用 YAML 锚点的方式来 `include` `.yaml`。你只能引用同一文件中的锚点。要重用来自不同 YAML 文件的配置，请使用[`!reference` 标签](#reference-tags) 或 [`extends` 关键字](#extends)。
`include` 支持以下引用方法： `include` 支持以下引用方法：
...@@ -337,7 +337,7 @@ workflow: ...@@ -337,7 +337,7 @@ workflow:
#### `include`变量[](#variables-with-include) #### `include`变量[](#variables-with-include)
您可以 在文件的部分中使用一些预定义的变量`include` `.codechina-ci.yml`： 你可以 在文件的部分中使用一些预定义的变量`include` `.codechina-ci.yml`：
```yaml ```yaml
include: include:
...@@ -351,7 +351,7 @@ include: ...@@ -351,7 +351,7 @@ include:
如果使用`include:local`，请确保`.codechina-ci.yml`文件和本地文件位于同一分支上。 如果使用`include:local`，请确保`.codechina-ci.yml`文件和本地文件位于同一分支上。
您不能通过 Git 子模块路径包含本地文件。 你不能通过 Git 子模块路径包含本地文件。
所有嵌套的包含都在同一个项目的范围内执行，因此可以使用本地、项目、远程或模板引用。 所有嵌套的包含都在同一个项目的范围内执行，因此可以使用本地、项目、远程或模板引用。
...@@ -362,7 +362,7 @@ include: ...@@ -362,7 +362,7 @@ include:
- local: '/templates/.codechina-ci-template.yml' - local: '/templates/.codechina-ci-template.yml'
``` ```
您还可以使用较短的语法来定义路径： 你还可以使用较短的语法来定义路径：
```yaml ```yaml
include: '.codechina-ci-production.yml' include: '.codechina-ci-production.yml'
...@@ -372,7 +372,7 @@ include: '.codechina-ci-production.yml' ...@@ -372,7 +372,7 @@ include: '.codechina-ci-production.yml'
##### `include:local`带通配符文件路径 ##### `include:local`带通配符文件路径
您可以在`include:local`中使用通配符路径（`*`和`**`）。 你可以在`include:local`中使用通配符路径（`*`和`**`）。
例子： 例子：
...@@ -404,7 +404,7 @@ include: ...@@ -404,7 +404,7 @@ include:
file: '/templates/.gitlab-ci-template.yml' file: '/templates/.gitlab-ci-template.yml'
``` ```
您还可以指定一个`ref`， 如果不指定值，则 `ref` 默认为项目的 `HEAD`： 你还可以指定一个`ref`， 如果不指定值，则 `ref` 默认为项目的 `HEAD`：
```yaml ```yaml
include: include:
...@@ -421,7 +421,7 @@ include: ...@@ -421,7 +421,7 @@ include:
file: '/templates/.gitlab-ci-template.yml' file: '/templates/.gitlab-ci-template.yml'
``` ```
所有[嵌套的引用]((#nested-includes))都在目标项目的范围内执行。您可以使用本地（相对于目标项目）、项目、远程或模板引用。 所有[嵌套的引用]((#nested-includes))都在目标项目的范围内执行。你可以使用本地（相对于目标项目）、项目、远程或模板引用。
##### 一个项目中的多个文件 ##### 一个项目中的多个文件
...@@ -445,7 +445,7 @@ include: ...@@ -445,7 +445,7 @@ include:
- remote: 'https://codechina.csdn.net/example-project/-/raw/main/.codechina-ci.yml' - remote: 'https://codechina.csdn.net/example-project/-/raw/main/.codechina-ci.yml'
``` ```
所有嵌套引用都以公共用户身份在没有上下文的情况下执行，因此您只能使用`include`公共项目或模板。 所有嵌套引用都以公共用户身份在没有上下文的情况下执行，因此你只能使用`include`公共项目或模板。
#### `include:template`[](#includetemplate) #### `include:template`[](#includetemplate)
...@@ -456,15 +456,15 @@ include: ...@@ -456,15 +456,15 @@ include:
```yaml ```yaml
# File sourced from the GitLab template collection # File sourced from the GitLab template collection
include: include:
- template: Auto-DevOps.gitlab-ci.yml - template: Auto-DevOps.codechina-ci.yml
``` ```
多个include:template文件： 多个include:template文件：
```yaml ```yaml
include: include:
- template: Android-Fastlane.gitlab-ci.yml - template: Android-Fastlane.codechina-ci.yml
- template: Auto-DevOps.gitlab-ci.yml - template: Auto-DevOps.codechina-ci.yml
``` ```
所有[嵌套引用](#nested-includes)仅在用户许可的情况下执行，因此可以使用项目、远程或模板引用。 所有[嵌套引用](#nested-includes)仅在用户许可的情况下执行，因此可以使用项目、远程或模板引用。
...@@ -483,7 +483,7 @@ include: ...@@ -483,7 +483,7 @@ include:
更多： 更多：
- 用法示例，请参见`.gitlab-ci.yml`文件中的 定义 `image` 。 - 用法示例，请参见`.codechina-ci.yml`文件中的 定义 `image` 。
- 详细使用信息，参考 Docker 集成文档。 - 详细使用信息，参考 Docker 集成文档。
#### `image:name` #### `image:name`
...@@ -504,7 +504,7 @@ include: ...@@ -504,7 +504,7 @@ include:
更多： 更多：
- 用法示例，请参见`.gitlab-ci.yml`文件中的定义`services`。 - 用法示例，请参见`.codechina-ci.yml`文件中的定义`services`。
- 详细使用信息，参考Docker集成文档。 - 详细使用信息，参考Docker集成文档。
- 示例服务，请参阅GitLab CI/CD 服务。 - 示例服务，请参阅GitLab CI/CD 服务。
...@@ -558,7 +558,7 @@ job: ...@@ -558,7 +558,7 @@ job:
- curl --request POST --header 'Content-Type: application/json' "https://gitlab/api/v4/projects" - curl --request POST --header 'Content-Type: application/json' "https://gitlab/api/v4/projects"
``` ```
要被视为有效的 YAML，您必须将整个命令用单引号括起来。如果命令已使用单引号，则应将它们更改为双引号 ( ")： 要被视为有效的 YAML，你必须将整个命令用单引号括起来。如果命令已使用单引号，则应将它们更改为双引号 ( ")：
```yaml ```yaml
job: job:
...@@ -566,7 +566,7 @@ job: ...@@ -566,7 +566,7 @@ job:
- 'curl --request POST --header "Content-Type: application/json" "https://gitlab/api/v4/projects"' - 'curl --request POST --header "Content-Type: application/json" "https://gitlab/api/v4/projects"'
``` ```
您可以使用[CI Lint](/docs/ci/lint)工具验证语法是否有效。 你可以使用[CI Lint](/docs/ci/lint)工具验证语法是否有效。
使用这些字符时也要小心： 使用这些字符时也要小心：
...@@ -585,7 +585,7 @@ job: ...@@ -585,7 +585,7 @@ job:
使用`before_script`定义应在每次流水线任务之前运行的命令组，但需要在`artifacts`恢复后。 使用`before_script`定义应在每次流水线任务之前运行的命令组，但需要在`artifacts`恢复后。
你在 `before_script` 其中指定的脚本与您在 main `script` 中指定的任何脚本连接在一起。组合后的脚本在单个 shell 中一起执行。 你在 `before_script` 其中指定的脚本与你在 main `script` 中指定的任何脚本连接在一起。组合后的脚本在单个 shell 中一起执行。
`before_script`如果在流水线任务中定义它，则可以覆盖全局定义： `before_script`如果在流水线任务中定义它，则可以覆盖全局定义：
...@@ -615,7 +615,7 @@ job: ...@@ -615,7 +615,7 @@ job:
你指定的`after_script`脚本在新 shell 中执行，与任何 `before_script`或`script`脚本分开 。通过这样： 你指定的`after_script`脚本在新 shell 中执行，与任何 `before_script`或`script`脚本分开 。通过这样：
- 将当前工作目录设置回默认值。 - 将当前流水线任务目录设置回默认值。
- 无法访问 `before_script` 或 `script` 中定义的脚本所做的更改，包括： - 无法访问 `before_script` 或 `script` 中定义的脚本所做的更改，包括：
- `script`脚本中导出的命令别名和变量。 - `script`脚本中导出的命令别名和变量。
- 工作树之外的更改（取决于运行程序执行程序），例如由 `before_script` 或 `script` 脚本安装的软件。 - 工作树之外的更改（取决于运行程序执行程序），例如由 `before_script` 或 `script` 脚本安装的软件。
...@@ -642,7 +642,7 @@ job: ...@@ -642,7 +642,7 @@ job:
#### `Script` 语法 #### `Script` 语法
您可以在`script`中使用语法来： 你可以在`script`中使用语法来：
- 将长命令拆分为多行命令。 - 将长命令拆分为多行命令。
- 使用颜色代码使流水线任务日志更易于查看。 - 使用颜色代码使流水线任务日志更易于查看。
...@@ -697,7 +697,7 @@ job 5: ...@@ -697,7 +697,7 @@ job 5:
当你使用自建的 Runner 时，默认情况下每个 Runner 一次仅运行一项流水线任务。如果流水线任务在不同的 Runner 上运行，它们可以并行运行。 当你使用自建的 Runner 时，默认情况下每个 Runner 一次仅运行一项流水线任务。如果流水线任务在不同的 Runner 上运行，它们可以并行运行。
如果您只有一个 Runner ，并且 Runner 的 `concurrent` 设置大于 1，则流水线任务可以并行运行。 如果你只有一个 Runner ，并且 Runner 的 `concurrent` 设置大于 1，则流水线任务可以并行运行。
#### `.pre` 和 `.post` #### `.pre` 和 `.post`
...@@ -710,7 +710,7 @@ job 5: ...@@ -710,7 +710,7 @@ job 5:
你必须在`.pre`或`.post`以外的至少一个阶段有一个流水线任务。 你必须在`.pre`或`.post`以外的至少一个阶段有一个流水线任务。
你不能更改 `.pre` 和 `.post` 的顺序，即使您在`.codechina-ci.yml`文件中不按顺序定义它们。例如，以下配置是等效的： 你不能更改 `.pre` 和 `.post` 的顺序，即使你在`.codechina-ci.yml`文件中不按顺序定义它们。例如，以下配置是等效的：
```yaml ```yaml
stages: stages:
...@@ -953,16 +953,16 @@ job: ...@@ -953,16 +953,16 @@ job:
- if: '$CI_PIPELINE_SOURCE == "schedule"' - if: '$CI_PIPELINE_SOURCE == "schedule"'
``` ```
- 如果管道用于合并请求，则第一个规则匹配，并且作业将添加到合并请求管道中 ，其属性为： - 如果流水线用于合并请求，则第一个规则匹配，并且流水线任务将添加到合并请求流水线中 ，其属性为：
- `when: manual` （手工作业） - `when: manual` （手工流水线任务）
- `allow_failure: true` （即使未运行手动作业，管道也会继续运行） - `allow_failure: true` （即使未运行手动流水线任务，流水线也会继续运行）
- 如果管道不是用于合并请求，则第一条规则不匹配，并评估第二条规则。 - 如果流水线不是用于合并请求，则第一条规则不匹配，并评估第二条规则。
- 如果管道是计划管道，则第二条规则匹配，并将作业添加到计划管道。没有定义属性，因此添加了： - 如果流水线是计划流水线，则第二条规则匹配，并将流水线任务添加到计划流水线。没有定义属性，因此添加了：
- `when: on_success` （默认） - `when: on_success` （默认）
- `allow_failure: false` （默认） - `allow_failure: false` （默认）
- 在所有其他情况下，没有规则匹配，因此不会将作业添加到任何其他管道。 - 在所有其他情况下，没有规则匹配，因此不会将流水线任务添加到任何其他流水线。
或者，你可以定义一组在少数情况下排除作业的 `rules`，但在所有其他情况下运行它们： 或者，你可以定义一组在少数情况下排除流水线任务的 `rules`，但在所有其他情况下运行它们：
```yaml ```yaml
job: job:
...@@ -975,15 +975,15 @@ job: ...@@ -975,15 +975,15 @@ job:
- when: on_success - when: on_success
``` ```
- 如果管道用于合并请求，则不会将作业添加到管道中。 - 如果流水线用于合并请求，则不会将流水线任务添加到流水线中。
- 如果管道是计划管道，则不会将作业添加到管道中。 - 如果流水线是计划流水线，则不会将流水线任务添加到流水线中。
- 在所有其他情况下，作业将添加到管道中，带有 `when: on_success`。 - 在所有其他情况下，流水线任务将添加到流水线中，带有 `when: on_success`。
> 如果您使用 `when:` 条款作为最终规则（不包括 `when: never`），则可能会同时启动两个管道。推送管道和合并请求管道都可以由同一事件触发（推送到源分支以获取开放合并请求）。 > 如果你使用 `when:` 条款作为最终规则（不包括 `when: never`），则可能会同时启动两个流水线。推送流水线和合并请求流水线都可以由同一事件触发（推送到源分支以获取开放合并请求）。
#### 避免重复的流水线[](#avoid-duplicate-pipelines) #### 避免重复的流水线[](#avoid-duplicate-pipelines)
如果作业使用rules，则单个操作（例如将提交推送到分支）可以触发多个管道。你不必为多种类型的管道显式配置规则来意外触发它们。 如果流水线任务使用rules，则单个操作（例如将提交推送到分支）可以触发多个流水线。你不必为多种类型的流水线显式配置规则来意外触发它们。
例如： 例如：
...@@ -996,13 +996,13 @@ job: ...@@ -996,13 +996,13 @@ job:
- when: always - when: always
``` ```
当`$CUSTOM_VARIABLE` 是 `false`时此作业不运行，但它在所有其他管道中运行，包括推（分支）和合并请求两个管道。使用此配置，每次推送到开放合并请求的源分支都会导致重复的管道。 当`$CUSTOM_VARIABLE` 是 `false`时此流水线任务不运行，但它在所有其他流水线中运行，包括推（分支）和合并请求两个流水线。使用此配置，每次推送到开放合并请求的源分支都会导致重复的流水线。
为避免重复管道，您可以： 为避免重复流水线，你可以：
- 使用 `CI_OPEN_MERGE_REQUESTS` CI/CD 变量 `workflow:rules` 在分支和合并请求管道之间进行切换，而不产生重复的管道。您还可以在单​​个作业规则中使用此变量。 - 使用 `CI_OPEN_MERGE_REQUESTS` CI/CD 变量 `workflow:rules` 在分支和合并请求流水线之间进行切换，而不产生重复的流水线。你还可以在单​​个流水线任务规则中使用此变量。
- 使用 `workflow` 指定只在分支管道或只在合并请求管道中运行。 - 使用 `workflow` 指定只在分支流水线或只在合并请求流水线中运行。
- 重写规则以仅在非常特定的情况下运行作业，并避免最终的 `when:` 规则： - 重写规则以仅在非常特定的情况下运行流水线任务，并避免最终的 `when:` 规则：
```yaml ```yaml
job: job:
...@@ -1011,9 +1011,9 @@ job: ...@@ -1011,9 +1011,9 @@ job:
- if: '$CUSTOM_VARIABLE == "true" && $CI_PIPELINE_SOURCE == "merge_request_event"' - if: '$CUSTOM_VARIABLE == "true" && $CI_PIPELINE_SOURCE == "merge_request_event"'
``` ```
您还可以通过更改作业规则来避免重复管道，以避免推送（分支）管道或合并请求管道。但是，如果您使用没有规则` workflow: rules` 的 `- when: always`，系统仍会显示管道警告。 你还可以通过更改流水线任务规则来避免重复流水线，以避免推送（分支）流水线或合并请求流水线。但是，如果你使用没有规则` workflow: rules` 的 `- when: always`，系统仍会显示流水线警告。
例如，以下不会触发双管道，但不推荐没有`workflow: rules`： 例如，以下不会触发双流水线，但不推荐没有`workflow: rules`：
```yaml ```yaml
job: job:
...@@ -1024,7 +1024,7 @@ job: ...@@ -1024,7 +1024,7 @@ job:
- when: always - when: always
``` ```
您不应在同一作业中同时包含推送和合并请求管道的 `workflow:rules`，以免防止重复管道： 你不应在同一流水线任务中同时包含推送和合并请求流水线的 `workflow:rules`，以免防止重复流水线：
```yaml ```yaml
job: job:
...@@ -1034,7 +1034,7 @@ job: ...@@ -1034,7 +1034,7 @@ job:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
``` ```
此外，不要将同一管道中的 `only/except` 作业与 `rules` 作业混合在一起。它可能不会引起 YAML 错误，但不同的默认行为的 `only/except` 和 `rules` 可能会导致一些难以解决的问题： 此外，不要将同一流水线中的 `only/except` 流水线任务与 `rules` 流水线任务混合在一起。它可能不会引起 YAML 错误，但不同的默认行为的 `only/except` 和 `rules` 可能会导致一些难以解决的问题：
```yaml ```yaml
job-with-no-rules: job-with-no-rules:
...@@ -1046,15 +1046,15 @@ job-with-rules: ...@@ -1046,15 +1046,15 @@ job-with-rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
``` ```
对于推送到分支的每个更改，都会运行重复的管道。一个分支管道运行单个作业 ( `job-with-no-rules`)，一个合并请求管道运行另一个作业 ( `job-with-rules`)。没有规则的作业默认为 `except: merge_requests`，因此 `job-with-no-rules` 在除合并请求之外的所有情况下都会运行。 对于推送到分支的每个更改，都会运行重复的流水线。一个分支流水线运行单个流水线任务 ( `job-with-no-rules`)，一个合并请求流水线运行另一个流水线任务 ( `job-with-rules`)。没有规则的流水线任务默认为 `except: merge_requests`，因此 `job-with-no-rules` 在除合并请求之外的所有情况下都会运行。
#### `rules:if` #### `rules:if`
使用 `rules:if` 条款指定何时向管道添加作业： 使用 `rules:if` 条款指定何时向流水线添加流水线任务：
- 如果if语句为真，则将作业添加到管道中。 - 如果if语句为真，则将流水线任务添加到流水线中。
- 如果某个if语句为真，但与 `when: never` 结合使用，则不会将作业添加到管道中。 - 如果某个if语句为真，但与 `when: never` 结合使用，则不会将流水线任务添加到流水线中。
- 如果没有任何if语句为真，则不会将作业添加到管道中。 - 如果没有任何if语句为真，则不会将流水线任务添加到流水线中。
`rules:if` 与 `only:variables` 略有不同，它的每个规则只接受一个表达式字符串而不是数组。任何一组要计算的表达式都可以通过使用 `&&` 或 `||` ，以及变量匹配运算符 (`==`, `!=`, `=~` 和 `!~`) 连成一个表达式。 `rules:if` 与 `only:variables` 略有不同，它的每个规则只接受一个表达式字符串而不是数组。任何一组要计算的表达式都可以通过使用 `&&` 或 `||` ，以及变量匹配运算符 (`==`, `!=`, `=~` 和 `!~`) 连成一个表达式。
...@@ -1076,33 +1076,33 @@ job: ...@@ -1076,33 +1076,33 @@ job:
- if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME' # Checking for the presence of a variable is possible - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME' # Checking for the presence of a variable is possible
``` ```
有关确定 `when` 作业的逻辑的一些详细信息： 有关确定 `when` 流水线任务的逻辑的一些详细信息：
- 如果提供的规则都不匹配，则作业将设置为 `when: never` 并且不包含在管道中。 - 如果提供的规则都不匹配，则流水线任务将设置为 `when: never` 并且不包含在流水线中。
- 没有任何条款的规则，例如 `when` 或 `allow_failure` 规则没有 `if` 或者没有 `changes`，总是匹配，并且总是在符合时使用。 - 没有任何条款的规则，例如 `when` 或 `allow_failure` 规则没有 `if` 或者没有 `changes`，总是匹配，并且总是在符合时使用。
- 如果规则匹配到并且未定义 `when`，则使用 `when` 规则定义的作业，，且未定义的情况下默认为 `on_success`。 - 如果规则匹配到并且未定义 `when`，则使用 `when` 规则定义的流水线任务，，且未定义的情况下默认为 `on_success`。
- 您可以为每个规则定义一次 `when`，也可以在作业级别定义一次，这将适用于所有规则。您不能在工作级别 `when` 与规则 `when` 混合使用。 - 你可以为每个规则定义一次 `when`，也可以在流水线任务级别定义一次，这将适用于所有规则。你不能在流水线任务级别 `when` 与规则 `when` 混合使用。
##### `rules` 的通用 `if` 条款 ##### `rules` 的通用 `if` 条款
对于类似于 `only/except` 关键字的行为，您可以检查 `$CI_PIPELINE_SOURCE` 变量的值： 对于类似于 `only/except` 关键字的行为，你可以检查 `$CI_PIPELINE_SOURCE` 变量的值：
| 值 | 描述| | 值 | 描述|
|-----|-----------| |-----|-----------|
| `api` | 由 pipelines API 触发的管道 | | `api` | 由 pipelines API 触发的流水线 |
| `chat` | 使用 GitLab ChatOps 命令创建的管道 | | `chat` | 使用 GitLab ChatOps 命令创建的流水线 |
| `external` | 当您使用 GitLab 以外的 CI 服务 | | `external` | 当你使用 GitLab 以外的 CI 服务 |
| `external_pull_request_event` | 在 GitHub 上创建或更新外部拉取请求时 | | `external_pull_request_event` | 在 GitHub 上创建或更新外部拉取请求时 |
| `merge_request_event` | 对于在创建或更新合并请求时创建的管道。需要启用合并请求管道、合并结果管道和 `merge trains` | | `merge_request_event` | 对于在创建或更新合并请求时创建的流水线。需要启用合并请求流水线、合并结果流水线和 `merge trains` |
| `parent_pipeline` | 对于由带有 `rules` 的父/子管道触发的管道。在子管道配置中使用此管道源，以便它可以由父管道触发 | | `parent_pipeline` | 对于由带有 `rules` 的父/子流水线触发的流水线。在子流水线配置中使用此流水线源，以便它可以由父流水线触发 |
| `pipeline` | 对于通过使用带有`CI_JOB_TOKEN`的API创建的多项目管道，或[ `trigger`](#trigger) 关键字 | | `pipeline` | 对于通过使用带有`CI_JOB_TOKEN`的API创建的多项目流水线，或[ `trigger`](#trigger) 关键字 |
| `push` | 对于由“git push”事件触发的管道，包括分支和标签 | | `push` | 对于由“git push”事件触发的流水线，包括分支和标签 |
| `schedule` | 计划管道 | | `schedule` | 计划流水线 |
| `trigger` | 对于使用 `trigger token` 创建的管道 | | `trigger` | 对于使用 `trigger token` 创建的流水线 |
| `web` | 对于使用 UI 中的 **流水线** 按钮创建的管道，来自项目的 **Devops > 流水线** 部分 | | `web` | 对于使用 UI 中的 **流水线** 按钮创建的流水线，来自项目的 **Devops > 流水线** 部分 |
| `webide` | 对于使用 `WebIDE` 创建的管道 | | `webide` | 对于使用 `WebIDE` 创建的流水线 |
以下示例在计划的管道或推送中将作业作为手动作业运行管道（到分支或标签），带有 `when: on_success`（默认）。它不会将作业添加到任何其他管道类型。 以下示例在计划的流水线或推送中将流水线任务作为手动流水线任务运行流水线（到分支或标签），带有 `when: on_success`（默认）。它不会将流水线任务添加到任何其他流水线类型。
```yaml ```yaml
job: job:
...@@ -1114,8 +1114,8 @@ job: ...@@ -1114,8 +1114,8 @@ job:
- if: '$CI_PIPELINE_SOURCE == "push"' - if: '$CI_PIPELINE_SOURCE == "push"'
``` ```
以下示例中当 `when: on_success` 时将在合并请求管道和计划管道运行作业 以下示例中当 `when: on_success` 时将在合并请求流水线和计划流水线运行流水线任务
。它不会在任何其他管道类型中运行。 。它不会在任何其他流水线类型中运行。
```yaml ```yaml
job: job:
...@@ -1138,10 +1138,10 @@ job: ...@@ -1138,10 +1138,10 @@ job:
#### `rules:changes` #### `rules:changes`
使用 `rules:changes` 当改特定文件时将作业添加到管道。 使用 `rules:changes` 当改特定文件时将流水线任务添加到流水线。
`rules: changes` 的工作方式与 [`only: changes` 和 `except: changes`](#onlychanges--exceptchanges) 相同。它接受一组路径。你应该只对分支使用 `rules: changes` `rules: changes` 的工作方式与 [`only: changes` 和 `except: changes`](#onlychanges--exceptchanges) 相同。它接受一组路径。你应该只对分支使用 `rules: changes`
管道或合并请求管道。例如，通常对合并请求管道使用`rules: changes`： 流水线或合并请求流水线。例如，通常对合并请求流水线使用`rules: changes`：
```yaml ```yaml
docker build: docker build:
...@@ -1156,12 +1156,12 @@ docker build: ...@@ -1156,12 +1156,12 @@ docker build:
在这个例子中： 在这个例子中：
- 如果管道是合并请求管道，将检查 `Dockerfile` 是否有更改。 - 如果流水线是合并请求流水线，将检查 `Dockerfile` 是否有更改。
- 如果 `Dockerfile` 已更改，则将作业作为手动作业添加到管道中，并且管道 - 如果 `Dockerfile` 已更改，则将流水线任务作为手动流水线任务添加到流水线中，并且流水线
即使作业没有被触发（`allow_failure: true`）也会继续运行。 即使流水线任务没有被触发（`allow_failure: true`）也会继续运行。
- 如果 `Dockerfile` 没有改变，则不会向任何管道添加作业（与 `when: never` 相同）。 - 如果 `Dockerfile` 没有改变，则不会向任何流水线添加流水线任务（与 `when: never` 相同）。
要将 `rules: changes` 用于分支管道而不是合并请求管道，将之前示例中的 `if:` 子句更改为： 要将 `rules: changes` 用于分支流水线而不是合并请求流水线，将之前示例中的 `if:` 子句更改为：
```yaml ```yaml
rules: rules:
...@@ -1171,12 +1171,12 @@ rules: ...@@ -1171,12 +1171,12 @@ rules:
要实现类似于 [`except:changes`](#onlychanges--exceptchanges) 的规则， 要实现类似于 [`except:changes`](#onlychanges--exceptchanges) 的规则，
使用 `when: never`。 使用 `when: never`。
> 您可以将 `rules: changes` 与其他管道类型一起使用，但不推荐使用。因为当没有 Git `push` 事件时，`rules: changes` 总是评估为 `true`。标记管道、计划管道等**没有**有 Git `push` 事件 > 你可以将 `rules: changes` 与其他流水线类型一起使用，但不推荐使用。因为当没有 Git `push` 事件时，`rules: changes` 总是评估为 `true`。标记流水线、计划流水线等**没有**有 Git `push` 事件
与他们有关。`rules: changes` 作业**始终**添加到这些管道中，如果没有 `if:` 语句将作业限制为分支或合并请求管道的话。 与他们有关。`rules: changes` 流水线任务**始终**添加到这些流水线中，如果没有 `if:` 语句将流水线任务限制为分支或合并请求流水线的话。
##### `rules:changes` 中的变量 ##### `rules:changes` 中的变量
您可以在 `rules:changes` 表达式中使用 CI/CD 变量来确定何时向管道添加作业： 你可以在 `rules:changes` 表达式中使用 CI/CD 变量来确定何时向流水线添加流水线任务：
```yaml ```yaml
docker build: docker build:
...@@ -1188,11 +1188,11 @@ docker build: ...@@ -1188,11 +1188,11 @@ docker build:
- $DOCKERFILES_DIR/* - $DOCKERFILES_DIR/*
``` ```
您可以将 `$` 字符用于变量和路径。例如，如果 `$DOCKERFILES_DIR` 变量存在，它的值被使用。如果不存在，则 `$` 被解释为路径的一部分。 你可以将 `$` 字符用于变量和路径。例如，如果 `$DOCKERFILES_DIR` 变量存在，它的值被使用。如果不存在，则 `$` 被解释为路径的一部分。
#### `rules:exists` #### `rules:exists`
当存储库中存在某些文件时，使用 `exists` 来运行作业。您可以使用一组路径。 当存储库中存在某些文件时，使用 `exists` 来运行流水线任务。你可以使用一组路径。
在以下示例中，如果存储库中的任何位置存在 `Dockerfile`，`job` 就会运行： 在以下示例中，如果存储库中的任何位置存在 `Dockerfile`，`job` 就会运行：
...@@ -1206,7 +1206,7 @@ job: ...@@ -1206,7 +1206,7 @@ job:
`exists` 的路径相对于项目目录 (`$CI_PROJECT_DIR`)，不能直接链接到项目目录之外。 `exists` 的路径相对于项目目录 (`$CI_PROJECT_DIR`)，不能直接链接到项目目录之外。
您可以使用 [glob](https://en.wikipedia.org/wiki/Glob_(programming)) 的模式在存储库中匹配任何目录中的多个文件： 你可以使用 [glob](https://en.wikipedia.org/wiki/Glob_(programming)) 的模式在存储库中匹配任何目录中的多个文件：
```yaml ```yaml
job: job:
...@@ -1222,9 +1222,9 @@ Glob 模式用 Ruby 解释 [`File.fnmatch`](https://docs.ruby-lang.org/en/2.7.0/ ...@@ -1222,9 +1222,9 @@ Glob 模式用 Ruby 解释 [`File.fnmatch`](https://docs.ruby-lang.org/en/2.7.0/
#### `rules:allow_failure` #### `rules:allow_failure`
您可以在 `rules:` 中使用 [`allow_failure: true`](#allow_failure) 来允许作业失败，或等待一个手动作业的操作，而不停止管道本身。所有使用 `rules:` 的作业在你没有定义 `allow_failure:`的情况下默认为 `allow_failure: false`。 你可以在 `rules:` 中使用 [`allow_failure: true`](#allow_failure) 来允许流水线任务失败，或等待一个手动流水线任务的操作，而不停止流水线本身。所有使用 `rules:` 的流水线任务在你没有定义 `allow_failure:`的情况下默认为 `allow_failure: false`。
规则级别的 `rules:allow_failure` 选项覆盖作业级别 [`allow_failure`](#allow_failure) 选项，仅在特定规则触发作业后进行。 规则级别的 `rules:allow_failure` 选项覆盖流水线任务级别 [`allow_failure`](#allow_failure) 选项，仅在特定规则触发流水线任务后进行。
```yaml ```yaml
job: job:
...@@ -1235,7 +1235,7 @@ job: ...@@ -1235,7 +1235,7 @@ job:
allow_failure: true allow_failure: true
``` ```
在此示例中，如果第一条规则匹配，则作业具有 `when: manual` 和 `allow_failure: true`。 在此示例中，如果第一条规则匹配，则流水线任务具有 `when: manual` 和 `allow_failure: true`。
#### `rules:variables` #### `rules:variables`
...@@ -1265,8 +1265,8 @@ job: ...@@ -1265,8 +1265,8 @@ job:
在以下示例中： 在以下示例中：
- 如果 `Dockerfile` 文件或 `/docker/scripts` 中的任何文件发生了变化，并且 `$VAR` == "string value"，则作业手动运行 - 如果 `Dockerfile` 文件或 `/docker/scripts` 中的任何文件发生了变化，并且 `$VAR` == "string value"，则流水线任务手动运行
- 否则，作业不包含在管道中。 - 否则，流水线任务不包含在流水线中。
```yaml ```yaml
docker build: docker build:
...@@ -1282,7 +1282,7 @@ docker build: ...@@ -1282,7 +1282,7 @@ docker build:
诸如 `branches` 或 `refs` 之类的关键字可用于 `only`/`except`，但在 `rules` 中不可用。 诸如 `branches` 或 `refs` 之类的关键字可用于 `only`/`except`，但在 `rules` 中不可用。
您可以使用括号 `[]` 和 `&&` 和 `||` 来构建更复杂的变量表达式。 你可以使用括号 `[]` 和 `&&` 和 `||` 来构建更复杂的变量表达式。
```yaml ```yaml
job1: job1:
...@@ -1294,10 +1294,10 @@ job1: ...@@ -1294,10 +1294,10 @@ job1:
### `only` / `except`[](#only--except) ### `only` / `except`[](#only--except)
您可以使用 `only` 和 `except` 来控制何时向管道添加作业。 你可以使用 `only` 和 `except` 来控制何时向流水线添加流水线任务。
- 使用 `only` 来定义作业何时运行。 - 使用 `only` 来定义流水线任务何时运行。
- 使用 `except` 定义作业何时 **不** 运行。 - 使用 `except` 定义流水线任务何时 **不** 运行。
四个关键字可以与 `only` 和 `except` 一起使用： 四个关键字可以与 `only` 和 `except` 一起使用：
...@@ -1308,9 +1308,9 @@ job1: ...@@ -1308,9 +1308,9 @@ job1:
#### `only:refs` / `except:refs` #### `only:refs` / `except:refs`
使用 `only:refs` 和 `except:refs` 关键字来控制何时将作业添加到基于分支名称或管道类型的管道。 使用 `only:refs` 和 `except:refs` 关键字来控制何时将流水线任务添加到基于分支名称或流水线类型的流水线。
**关键字类型**：工作关键字。您只能将其用作工作的一部分。 **关键字类型**：流水线任务关键字。你只能将其用作流水线任务的一部分。
**可能的输入**：包含任意数量的数组： **可能的输入**：包含任意数量的数组：
...@@ -1320,18 +1320,18 @@ job1: ...@@ -1320,18 +1320,18 @@ job1:
| **关键词** | **说明** | | **关键词** | **说明** |
| -------------------------|-----------------| | -------------------------|-----------------|
| `api` | 对于由 pipelines API 触发的管道 | | `api` | 对于由 pipelines API 触发的流水线 |
| `branches` | 当管道的 Git 引用是分支时 | | `branches` | 当流水线的 Git 引用是分支时 |
| `chat` | 对于使用 ChatOps命令创建的管道 | | `chat` | 对于使用 ChatOps命令创建的流水线 |
| `external` | 当您使用 GitLab 以外的 CI 服务时 | | `external` | 当你使用 GitLab 以外的 CI 服务时 |
| `external_pull_requests` | 在 GitHub 上创建或更新外部拉取请求时 | | `external_pull_requests` | 在 GitHub 上创建或更新外部拉取请求时 |
| `merge_request` | 对于在创建或更新合并请求时创建的管道。启用合并请求管道、合并的结果管道 和 `merge trains` | | `merge_request` | 对于在创建或更新合并请求时创建的流水线。启用合并请求流水线、合并的结果流水线 和 `merge trains` |
| `pipelines` | 对于通过使用带有`CI_JOB_TOKEN`的API创建的多项目管道，或[ `trigger`](#trigger) 关键字 | | `pipelines` | 对于通过使用带有`CI_JOB_TOKEN`的API创建的多项目流水线，或[ `trigger`](#trigger) 关键字 |
| `push` | 对于由“git push”事件触发的管道，包括分支和标签 | | `push` | 对于由“git push”事件触发的流水线，包括分支和标签 |
| `schedules` | 计划管道 | | `schedules` | 计划流水线 |
| `tags` | 当管道的 Git 引用是标签时 | | `tags` | 当流水线的 Git 引用是标签时 |
| `triggers` | 对于使用 `trigger token` 创建的管道 | | `triggers` | 对于使用 `trigger token` 创建的流水线 |
| `web` | 对于使用 UI 中的 **流水线** 按钮创建的管道，来自项目的 **DevOps > 流水线** 部分 | | `web` | 对于使用 UI 中的 **流水线** 按钮创建的流水线，来自项目的 **DevOps > 流水线** 部分 |
**`only:refs` 和 `except:refs` 示例**： **`only:refs` 和 `except:refs` 示例**：
...@@ -1353,7 +1353,7 @@ job2: ...@@ -1353,7 +1353,7 @@ job2:
**更多细节：** **更多细节：**
- 计划管道在特定分支上运行，因此作业配置为 `only: branch` 也可以计划管道上运行。添加 `except: schedules` 以防止使用 `only: branch` 的作业在预定管道上运行。 - 计划流水线在特定分支上运行，因此流水线任务配置为 `only: branch` 也可以计划流水线上运行。添加 `except: schedules` 以防止使用 `only: branch` 的流水线任务在预定流水线上运行。
- `only` 或 `except` 不使用任何其他关键字等价于 `only: refs` 或 `except: refs`。比如下面两个job的配置是一样的行为： - `only` 或 `except` 不使用任何其他关键字等价于 `only: refs` 或 `except: refs`。比如下面两个job的配置是一样的行为：
```yaml ```yaml
...@@ -1369,7 +1369,7 @@ job2: ...@@ -1369,7 +1369,7 @@ job2:
- branches - branches
``` ```
- 如果作业不使用 `only`、`except` 或 [`rules`](#rules)，则 `only` 默认设置为 `branches` - 如果流水线任务不使用 `only`、`except` 或 [`rules`](#rules)，则 `only` 默认设置为 `branches`
和`tag`。 和`tag`。
例如，`job1` 和 `job2` 是等价的： 例如，`job1` 和 `job2` 是等价的：
...@@ -1386,10 +1386,10 @@ job2: ...@@ -1386,10 +1386,10 @@ job2:
``` ```
#### `only:variables` / `except:variables` #### `only:variables` / `except:variables`
使用 `only:variables` 或 `except:variables` 关键字来控制何时添加作业 使用 `only:variables` 或 `except:variables` 关键字来控制何时添加流水线任务
到管道，基于 [CI/CD 变量](/docs/ci/vaiables) 的状态。 到流水线，基于 [CI/CD 变量](/docs/ci/vaiables) 的状态。
**关键字类型**：工作关键字。您只能将其用作工作的一部分。 **关键字类型**：流水线任务关键字。你只能将其用作流水线任务的一部分。
**可能的输入**：[CI/CD 变量表达式](/docs/ci/variabless#cicd-variable-expressions) 的数组。 **可能的输入**：[CI/CD 变量表达式](/docs/ci/variabless#cicd-variable-expressions) 的数组。
...@@ -1406,15 +1406,15 @@ deploy: ...@@ -1406,15 +1406,15 @@ deploy:
#### `only:changes` / `except:changes` #### `only:changes` / `except:changes`
当 Git 推送事件修改文件时，使用 `changes` 关键字和 `only` 来运行一个作业，或者使用 `except` 来跳过一个作业。 当 Git 推送事件修改文件时，使用 `changes` 关键字和 `only` 来运行一个流水线任务，或者使用 `except` 来跳过一个流水线任务。
在具有以下引用的管道中使用`changes`： 在具有以下引用的流水线中使用`changes`：
- `分支` - `分支`
- `external_pull_requests` - `external_pull_requests`
- `merge_requests` - `merge_requests`
**关键字类型**：工作关键字。您只能将其用作工作的一部分。 **关键字类型**：流水线任务关键字。你只能将其用作流水线任务的一部分。
**可能的输入**：包含任意数量的数组： **可能的输入**：包含任意数量的数组：
...@@ -1441,14 +1441,14 @@ docker build: ...@@ -1441,14 +1441,14 @@ docker build:
**更多细节**： **更多细节**：
- 如果你使用除 `branches`、`external_pull_requests` 或 `merge_requests` 以外的引用，`changes` 无法确定给定文件是新文件还是旧文件，并且总是返回 `true`。 - 如果你使用除 `branches`、`external_pull_requests` 或 `merge_requests` 以外的引用，`changes` 无法确定给定文件是新文件还是旧文件，并且总是返回 `true`。
- 如果您将 `only: changes` 与其他引用一起使用，作业将忽略更改并始终运行。 - 如果你将 `only: changes` 与其他引用一起使用，流水线任务将忽略更改并始终运行。
- 如果您将 `except: changes` 与其他引用一起使用，作业将忽略更改并且 - 如果你将 `except: changes` 与其他引用一起使用，流水线任务将忽略更改并且
#### `only:kubernetes` / `except:kubernetes` #### `only:kubernetes` / `except:kubernetes`
当 Kubernetes 服务在项目中处于活动状态时，使用 `only:kubernetes` 或 `except:kubernetes` 来控制是否将作业添加到管道中。 当 Kubernetes 服务在项目中处于活动状态时，使用 `only:kubernetes` 或 `except:kubernetes` 来控制是否将流水线任务添加到流水线中。
**关键字类型**：特定于工作。您只能将其用作工作的一部分。 **关键字类型**：特定于流水线任务。你只能将其用作流水线任务的一部分。
**可能的输入**：`kubernetes` 策略只接受 `active` 关键字。 **可能的输入**：`kubernetes` 策略只接受 `active` 关键字。
...@@ -1460,20 +1460,20 @@ deploy: ...@@ -1460,20 +1460,20 @@ deploy:
kubernetes: active kubernetes: active
``` ```
在此示例中，`deploy` 作业仅在 Kubernetes 服务处于活动状态时运行在项目中。 在此示例中，`deploy` 流水线任务仅在 Kubernetes 服务处于活动状态时运行在项目中。
### `needs`[](#needs) ### `needs`[](#needs)
使用 `needs:` 来乱序执行作业。工作之间的关系可使用 `needs` 可视化为有向无环图。 使用 `needs:` 来乱序执行流水线任务。流水线任务之间的关系可使用 `needs` 可视化为有向无环图。
您可以忽略阶段排序并运行一些作业，而无需等待其他作业完成。多个阶段的作业可以同时运行。 你可以忽略阶段排序并运行一些流水线任务，而无需等待其他流水线任务完成。多个阶段的流水线任务可以同时运行。
以下示例创建四个执行路径： 以下示例创建四个执行路径：
- Linter：`lint` 作业立即运行，无需等待 `build` 阶段完成，因为它没有需求（`needs: []`）。 - Linter：`lint` 流水线任务立即运行，无需等待 `build` 阶段完成，因为它没有需求（`needs: []`）。
- Linux 路径：`linux:rspec` 和 `linux:rubocop` 作业在 `linux:build` 运行后立即运行，作业无需等待`mac:build`完成即可完成。 - Linux 路径：`linux:rspec` 和 `linux:rubocop` 流水线任务在 `linux:build` 运行后立即运行，流水线任务无需等待`mac:build`完成即可完成。
- macOS 路径：`mac:rspec` 和 `mac:rubocop` 作业在 `mac:build` 运行后立即运行，作业完成，无需等待 `linux:build` 完成。 - macOS 路径：`mac:rspec` 和 `mac:rubocop` 流水线任务在 `mac:build` 运行后立即运行，流水线任务完成，无需等待 `linux:build` 完成。
- `production` 作业在所有先前作业完成后立即运行，即：`linux:build`、`linux:rspec`、`linux:rubocop`、`mac:build`、`mac:rspec`、`mac:rubocop`。 - `production` 流水线任务在所有先前流水线任务完成后立即运行，即：`linux:build`、`linux:rspec`、`linux:rubocop`、`mac:build`、`mac:rspec`、`mac:rubocop`。
```yaml ```yaml
linux:build: linux:build:
...@@ -1508,19 +1508,19 @@ production: ...@@ -1508,19 +1508,19 @@ production:
#### 要求和限制 #### 要求和限制
- 在 GitLab 13.9 及更早版本中，如果 `needs:` 指的是因 `only`、`except` 或 `rules` 等可能不会添加到的作业，则管道可能无法创建。 - 在 GitLab 13.9 及更早版本中，如果 `needs:` 指的是因 `only`、`except` 或 `rules` 等可能不会添加到的流水线任务，则流水线可能无法创建。
- `needs:` 数组中单个作业可以需要的最大作业数是有限的，限制是：50。 - `needs:` 数组中单个流水线任务可以需要的最大流水线任务数是有限的，限制是：50。
- 如果 `needs:` 是指使用 [`parallel`](#parallel) 关键字的作业，这取决于并行创建的所有工作，而不仅仅是一项工作。它也下载默认情况下来自所有并行作业的 `artifacts`。如果 `artifacts` 有相同的名称，它们会相互覆盖，并且只保存最后下载的一个。 - 如果 `needs:` 是指使用 [`parallel`](#parallel) 关键字的流水线任务，这取决于并行创建的所有流水线任务，而不仅仅是一项流水线任务。它也下载默认情况下来自所有并行流水线任务的 `artifacts`。如果 `artifacts` 有相同的名称，它们会相互覆盖，并且只保存最后下载的一个。
- `needs:` 类似于 `dependencies:`，因为它必须使用先前阶段的作业，这意味着不可能创建循环依赖项。根据工作当前阶段也不可能。 - `needs:` 类似于 `dependencies:`，因为它必须使用先前阶段的流水线任务，这意味着不可能创建循环依赖项。根据流水线任务当前阶段也不可能。
- 必须为所有有关键字 `needs:` 或被其引用的作业明确定义阶段。 - 必须为所有有关键字 `needs:` 或被其引用的流水线任务明确定义阶段。
#### 使用 `needs` 下载 `artifacts` #### 使用 `needs` 下载 `artifacts`
当作业使用 `needs` 时，默认情况下它不再下载前一阶段的所有 `artifacts`，因为具有 `medds` 的作业可以在早期阶段完成之前开始。当存在 `needs` 时，你只能从 `needs:` 配置中列出的作业下载 `artifacts`。 当流水线任务使用 `needs` 时，默认情况下它不再下载前一阶段的所有 `artifacts`，因为具有 `medds` 的流水线任务可以在早期阶段完成之前开始。当存在 `needs` 时，你只能从 `needs:` 配置中列出的流水线任务下载 `artifacts`。
使用 `artifacts: true`（默认值）或 `artifacts: false` 在出现在使用 `needs` 的作业中来控制何时下载 `artifacts`。 使用 `artifacts: true`（默认值）或 `artifacts: false` 在出现在使用 `needs` 的流水线任务中来控制何时下载 `artifacts`。
在以下示例中，`rspec` 作业下载了 `build_job` 的 `artifacts`，但是`rubocop` 工作不会： 在以下示例中，`rspec` 流水线任务下载了 `build_job` 的 `artifacts`，但是`rubocop` 流水线任务不会：
```yaml ```yaml
build_job: build_job:
...@@ -1542,7 +1542,7 @@ rubocop: ...@@ -1542,7 +1542,7 @@ rubocop:
artifacts: false artifacts: false
``` ```
在以下示例中，`rspec` 作业从所有三个 `build_jobs` 中下载 `artifacts`。其中 `artifacts` 设置为： 在以下示例中，`rspec` 流水线任务从所有三个 `build_jobs` 中下载 `artifacts`。其中 `artifacts` 设置为：
- 对 `build_job_1` 设置为 `true`。 - 对 `build_job_1` 设置为 `true`。
- 对于 `build_job_2` 和 `build_job_3`，默认为 `true`。 - 对于 `build_job_2` 和 `build_job_3`，默认为 `true`。
...@@ -1558,7 +1558,7 @@ rspec: ...@@ -1558,7 +1558,7 @@ rspec:
#### `needs` 跨项目下载 `artifacts` #### `needs` 跨项目下载 `artifacts`
管道中使用 `needs` 从最多五个作业下载 `artifacts`： 流水线中使用 `needs` 从最多五个流水线任务下载 `artifacts`：
- [在同一项目中的其他 ref](#artifact-downloads-between-pipelines-in-the-same-project) - [在同一项目中的其他 ref](#artifact-downloads-between-pipelines-in-the-same-project)
- 在不同的项目、组和命名空间中 - 在不同的项目、组和命名空间中
...@@ -1575,1201 +1575,957 @@ build_job: ...@@ -1575,1201 +1575,957 @@ build_job:
artifacts: true artifacts: true
``` ```
`build_job` 从 `group/project-name` 项目的 `main` 分支上最新成功的 `build-1` 作业下载 `artifacts`。如果项目在 `build_job` 从 `group/project-name` 项目的 `main` 分支上最新成功的 `build-1` 流水线任务下载 `artifacts`。如果项目在
相同的组或命名空间，您可以从 `project:` 关键字中省略它们。例如， 相同的组或命名空间，你可以从 `project:` 关键字中省略它们。例如，
`project: group/project-name` 或 `project: project-name`。 `project: group/project-name` 或 `project: project-name`。
运行管道的用户必须至少具有对组或项目的“报告者”访问权限，或者组/项目必须具有公开可见性。 运行流水线的用户必须至少具有对组或项目的`Reporter`访问权限，或者组/项目是公开可见的。
##### 同一项目中管道之间的工件下载 ##### 同一项目中流水线间的 `artifacts` 下载
使用 `needs` 从当前项目中的不同管道下载工件。 使用 `needs` 从当前项目中的不同流水线下载 `artifacts`。将 `project` 关键字设置为当前项目的名称，并指定一个 `ref`。
将 `project` 关键字设置为当前项目的名称，并指定一个引用。
在以下示例中，`build_job` 下载最新成功的工件 在以下示例中，`build_job` 从 ref 为 `other-ref` 的 `build-1` 流水线任务下载最新成功的 `artifacts`：
带有 `other-ref` ref 的 `build-1` 作业：
```yaml ```yaml
构建_作业： build_job:
阶段：构建 stage: build
脚本： script:
- ls -lhR - ls -lhR
需要： needs:
- 项目：组/相同项目名称 - project: group/same-project-name
工作：build-1 job: build-1
参考：其他参考 ref: other-ref
文物：真实 artifacts: true
`` ```
对 `project:`、`job:` 和 `ref` 的 CI/CD 变量支持[介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/202093) `project:`、`job:` 和 `ref` 也支持 CI/CD 变量形式的参数。
在 GitLab 13.3 中。[已删除功能标志](https://gitlab.com/gitlab-org/gitlab/-/issues/235761) 在 GitLab 13.4 中。
例如： 例如：
```yaml ```yaml
构建_作业： build_job:
阶段：构建 stage: build
脚本： script:
- ls -lhR - ls -lhR
需要： needs:
- 项目：$CI_PROJECT_PATH - project: $CI_PROJECT_PATH
工作：$DEPENDENCY_JOB_NAME job: $DEPENDENCY_JOB_NAME
参考：$ARTIFACTS_DOWNLOAD_REF ref: $ARTIFACTS_DOWNLOAD_REF
文物：真实 artifacts: true
`` ```
您无法从在 [`parallel:`](#parallel) 中运行的作业下载工件。
要在 [父子管道](../parent_child_pipelines.md) 之间下载工件， 你无法从 [`parallel:`](#parallel) 中运行的流水线任务下载 `artifacts`。
使用 [`needs:pipeline`](#artifact-downloads-to-child-pipelines)。
您不应从与正在运行的管道相同的 ref 下载工件。同时 要在父子流水线之间下载 `artifacts`，使用 [`needs:pipeline`](#artifact-downloads-to-child-pipelines)。
在同一个 ref 上运行的管道可能会覆盖工件。
##### 工件下载到子管道 你不应从相同的 ref 下正在运行的流水线下载 `artifacts`，在同一个 ref 上运行的流水线可能会覆盖 `artifacts`。
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/255983) 在 GitLab v13.7 中。 ##### `artifacts` 下载到子流水线
[子管道](../parent_child_pipelines.md) 可以从作业中下载工件 子流水线可以从它的父流水线或同一父流水线中的另一个子流水线流水线任务中下载 `artifacts`。
它的父管道或同一父子管道层次结构中的另一个子管道。
例如，使用以下具有创建一些工件的作业的父管道： 例如，以下是一个会创建一些 `artifacts` 的父流水线：
```yaml ```yaml
创建工件： create-artifact:
阶段：构建 stage: build
脚本：回显“样本工件”> artifact.txt script: echo 'sample artifact' > artifact.txt
文物： artifacts:
路径：[artifact.txt] paths: [artifact.txt]
子管道： child-pipeline:
阶段：测试 stage: test
扳机： trigger:
包括：child.yml include: child.yml
策略：依赖 strategy: depend
变量： variables:
PARENT_PIPELINE_ID：$CI_PIPELINE_ID PARENT_PIPELINE_ID: $CI_PIPELINE_ID
`` ```
子管道中的作业可以从“create-artifact”作业中下载工件 子流水线中的流水线任务可以从父流水线：`create-artifact` 流水线任务中下载 `artifacts`：
父管道：
```yaml ```yaml
使用神器： use-artifact:
脚本：cat artifact.txt script: cat artifact.txt
需要： needs:
- 管道：$PARENT_PIPELINE_ID - pipeline: $PARENT_PIPELINE_ID
工作：创建工件 job: create-artifact
`` ```
`pipeline` 属性接受一个管道 ID，它必须是一个存在的管道 `pipeline` 接受一个流水线 ID，它必须是一个存在于给定流水线的相同父流水线层次结构中的流水线。
在给定管道的相同父子管道层次结构中。
`pipeline` 属性不接受当前的管道 ID (`$CI_PIPELINE_ID`)。 `pipeline` 不接受当前的流水线 ID (`$CI_PIPELINE_ID`)。如果要从当前流水线中的流水线任务下载 `artifacts`，请使用 `needs` 的基本形式。
要从当前管道中的作业下载工件，请使用 [`needs`](#artifact-downloads-with-needs) 的基本形式。
#### 可选`需要` #### 可选 `needs`
> - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/30680) 在 GitLab 13.10 中。 如果需要的是流水线中有时不存在的流水线任务，请在 `needs` 配置中添加 `optional: true`。如果未定义，`optional: false` 是默认值。
> - [已删除功能标志](https://gitlab.com/gitlab-org/gitlab/-/issues/323891) 在 GitLab 14.0 中。
要需要管道中有时不存在的作业，请添加 `optional: true` 使用 [`rules`](#rules)、[`only` 或 `except`](#only--except) 的流水线任务可能并不总是存在于流水线中。当流水线启动时，在运行之前它会检查 `needs` 的关系。如果没有设置`optional: true`，且需要的关系指向不存在的流水线任务时会阻止流水线启动并导致流水线产生一个类似如下错误：
到`needs` 配置。如果未定义，`optional: false` 是默认值。
使用 [`rules`](#rules)、[`only` 或 `except`](#only--except) 的作业可能 - `'job1' job needs 'job2' job, but it was not added to the pipeline`
并不总是存在于管道中。当管道启动时，它会检查“需求”
跑步前的关系。没有`optional: true`，需要的关系
指向不存在的作业会阻止管道启动并导致管道
错误类似于：
- `'job1' 作业需要'job2' 作业，但它没有被添加到管道中` 在下面这个例子中：
在这个例子中： - 当分支为默认分支时，流水线中存在 `build` 流水线任务，`rspec` 流水线任务在开始之前等待它完成。
- 当分支不是默认分支时，流水线中不存在 `build` 流水线任务。`rspec` 流水线任务立即运行（类似于 `needs: []`），因为它的 `needs` 与 `build` 流水线任务的关系是可选的。
- 当分支为默认分支时，管道中存在`build`作业，`rspec`
作业在开始之前等待它完成。
- 当分支不是默认分支时，管道中不存在 `build` 作业。
`rspec` 作业立即运行（类似于 `needs: []`），因为它的 `needs`
与 `build` 作业的关系是可选的。
```yaml ```yaml
建造： build:
阶段：构建 stage: build
规则： rules:
- 如果：$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
规格： rspec:
阶段：测试 stage: test
需要： needs:
- 工作：构建 - job: build
可选：真 optional: true
`` ```
###`标签` ### `tags`[](#tags)
使用 `tags` 从所有跑步者的列表中选择一个特定的跑步者 使用 `tags` 从所有的 Runner 列表中选择一个特定的可用于项目的 Runner。
可用于项目。
当您注册跑步者时，您可以指定跑步者的标签，例如 当你注册 Runner 时，你可以指定 Runner 的 tag，比如`ruby`、`postgres`、`development`等。
例如`ruby`、`postgres`、`development`。
在以下示例中，作业由运行程序运行 在以下示例中，流水线任务由同时定义了 `ruby` 和 `postgres` tag 的 Runner 运行。
定义了 `ruby` 和 `postgres` 标签。
```yaml ```yaml
工作： job:
标签： tags:
- 红宝石 - ruby
- postgres - postgres
`` ```
您可以使用标签在不同平台上运行不同的作业。为了 你可以使用 tag 在不同平台上运行不同的流水线任务。比如，如果你有一个带有 `osx` 标签的 OS X Runner 和一个带有 `windows` 标签的 Windows Runner，你可以通过以下设置在每个平台上运行一个流水线任务：
例如，如果您有一个带有“osx”标签的 OS X 运行器和一个带有标签的 Windows 运行器
`windows`，你可以在每个平台上运行一个作业：
```yaml ```yaml
窗口工作： windows job:
阶段： stage:
- 建造 - build
标签： tags:
- 窗户 - windows
脚本： script:
- echo 你好，%USERNAME%！ - echo Hello, %USERNAME%!
osx 工作： osx job:
阶段： stage:
- 建造 - build
标签： tags:
- osx - osx
脚本： script:
- echo "你好，$USER！" - echo "Hello, $USER!"
`` ```
###`allow_failure` ### `allow_failure`[](#allow_failure)
当您想让作业失败而不影响 CI 的其余部分时，请使用 `allow_failure` 当你想让流水线任务失败而不影响 CI 组合的其余部分时，请使用 `allow_failure`。它的默认值为 `false`，[manual](#whenmanual) 使用
套房。默认值为 `false`，除了 [manual](#whenmanual) 使用 `when: manual` 语法时除外。
`when: manual` 语法。
在使用 [`rules:`](#rules) 的作业中，所有作业默认为 `allow_failure: false`， 在使用 [`rules:`](#rules) 的流水线任务中，所有流水线任务默认为 `allow_failure: false`，*包括* `when: manual` 流水线任务。
*包括*`when：手动`作业。
当 `allow_failure` 设置为 `true` 并且作业失败时，作业会在 UI 中显示橙色警告。 当 `allow_failure` 设置为 `true` 并且流水线任务失败时，流水线任务会在 UI 中显示橙色警告。但是，流水线的逻辑流仍会将流水线任务视为
但是，管道的逻辑流将作业视为 成功/通过，并且该流水线不会被 block。
成功/通过，并且没有被阻止。
假设所有其他作业都成功，​​作业的阶段及其管道 假设所有其他流水线任务都成功，​​流水线任务的 stage 及其流水线显示相同的橙色警告。但是，与之关联的提交被标记为 `passed`，并且没有警告提示。
显示相同的橙色警告。但是，关联的提交被标记为
“通过”，没有警告。
在以下示例中，`job1` 和 `job2` 并行运行。如果`job1` 在以下示例中，`job1` 和 `job2` 并行运行，如果 `job1` 失败，它不会停止下一个阶段的运行，因为它被标记为 `allow_failure: true`:
失败，它不会停止下一个阶段的运行，因为它被标记为
`allow_failure: true`:
```yaml ```yaml
工作1： job1:
阶段：测试 stage: test
脚本： script:
- execute_script_that_will_fail - execute_script_that_will_fail
allow_failure: 真 allow_failure: true
工作2： job2:
阶段：测试 stage: test
脚本： script:
- execute_script_that_will_succeed - execute_script_that_will_succeed
工作3： job3:
阶段：部署 stage: deploy
脚本： script:
- deploy_to_staging - deploy_to_staging
`` ```
#### `allow_failure:exit_codes` #### `allow_failure:exit_codes`
> - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/273157) 在 GitLab 13.8 中。 使用 `allow_failure:exit_codes` 动态控制是否应该允许流水线任务失败。你可以列出哪些退出代码不被视为失败。对于任何其他退出代码，流水线任务失败：
> - [已删除功能标志](https://gitlab.com/gitlab-org/gitlab/-/issues/292024) 在 GitLab 13.9 中。
使用 `allow_failure:exit_codes` 动态控制是否应该允许作业
失败。您可以列出哪些退出代码不被视为失败。作业失败
对于任何其他退出代码：
```yaml ```yaml
test_job_1： test_job_1:
脚本： script:
- echo "运行导致退出代码 1 的脚本。此作业失败。" - echo "Run a script that results in exit code 1. This job fails."
- 退出 1 - exit 1
允许失败： allow_failure:
退出代码：137 exit_codes: 137
test_job_2： test_job_2:
脚本： script:
- echo "运行导致退出代码 137 的脚本。允许此作业失败。" - echo "Run a script that results in exit code 137. This job is allowed to fail."
- 退出 137 - exit 137
允许失败： allow_failure:
退出代码： exit_codes:
- 137 - 137
- 255 - 255
`` ```
###`什么时候` ### `when`[](#when)
使用 `when` 来实现在失败或不顾一切情况下运行的作业 使用 `when` 来实现在失败或不管失败的情况下运行的流水线任务。
失败。
`when` 的有效值为： `when` 的有效值为：
1. `on_success`（默认）- 只有在早期阶段的所有作业都成功时才执行作业， 1. `on_success`（默认）- 只有在早期阶段的所有流水线任务都成功时才执行流水线任务，或者当它们设置了 `allow_failure: true` 时，总是视作成功的。
或者被认为是成功的，因为它们有 `allow_failure: true`。 1. `on_failure` - 仅在较早阶段的至少一项流水线任务失败时才执行流水线任务。
1. `on_failure` - 仅在较早阶段的至少一项作业失败时才执行作业。 1. `always` - 无论早期阶段的流水线任务状态如何，都执行流水线任务。
1. `always` - 无论早期阶段的作业状态如何，都执行作业。 1. `manual` - [手动](#whenmanual) 执行流水线任务。
1. `manual` - [手动](#whenmanual) 执行作业。 1. `delayed` - [延迟流水线任务的执行](#whendelayed) 指定的持续时间。
1. `delayed` - [延迟作业的执行](#whendelayed) 指定的持续时间。 1. `never`：
在 GitLab 11.14 中添加。 - 使用流水线任务 [`rules`](#rules)，不执行流水线任务。
1.`从不`： - 使用 [`workflow:rules`](#workflow)，不运行流水线。
- 使用作业 [`rules`](#rules)，不要执行作业。
- 使用 [`workflow:rules`](#workflow)，不要运行管道。
在以下示例中，脚本： 在以下示例中，脚本代码：
1. 只有当`build_job`失败时才执行`cleanup_build_job`。 1. 只有当 `build_job` 失败时才执行 `cleanup_build_job`。
1. 始终执行`cleanup_job`作为管道的最后一步，不管 1. 始终执行 `cleanup_job` 作为流水线的最后一步，不管成功或失败。
成功或失败。 1. 在 UI 中手动运行时执行 `deploy_job`。
1. 在 GitLab UI 中手动运行时执行 `deploy_job`。
```yaml ```yaml
阶段： stages:
- 建造 - build
- 清理_构建 - cleanup_build
- 测试 - test
- 部署 - deploy
- 清理 - cleanup
构建_作业： build_job:
阶段：构建 stage: build
脚本： script:
- 进行构建 - make build
cleanup_build_job: cleanup_build_job:
阶段：cleanup_build stage: cleanup_build
脚本： script:
- 失败时清理构建 - cleanup build when failed
时间：on_failure when: on_failure
测试工作：
阶段：测试
脚本：
- 进行测试
部署_作业： test_job:
阶段：部署 stage: test
脚本： script:
- 进行部署 - make test
时间：手动
清理工作： deploy_job:
阶段：清理 stage: deploy
脚本： script:
- 工作后的清理 - make deploy
什么时候：总是 when: manual
``
####`when:manual` cleanup_job:
stage: cleanup
script:
- cleanup after jobs
when: always
```
手动作业是一种不会自动执行的作业，必须明确 #### `when:manual`[](#whenmanual)
由用户启动。您可能希望将手动作业用于部署到生产之类的事情。
要制作作业手册，请将 `when: manual` 添加到其配置中。 手动流水线任务是一种不会自动执行的流水线任务，它必须由用户启动。你可能希望将手动流水线任务用于部署到生产之类的事情。
管道启动时，手动作业显示为已跳过且不会自动运行。 要实现一个手动的流水线，请将 `when: manual` 添加到其配置中。
它们可以从管道、作业、[环境](../environments/index.md#configure-manual-deployments)、
和部署视图。
手动作业可以是可选的或阻塞的： 流水线启动时，手动流水线任务显示为已跳过且不会自动运行。它们可以从流水线、流水线任务、环境和部署视图中启动执行。
- **可选**：手动作业默认设置为 [`allow_failure: true](#allow_failure) 手动流水线任务可以是可选的或阻塞的：
并且被认为是可选的。可选手工作业的状态没有贡献
到整体管道状态。即使所有手动作业都失败，管道也可以成功。
- **阻塞**：要进行阻塞手动作业，请将 `allow_failure: false` 添加到其配置中。 - **可选**：手动流水线任务默认设置为 [`allow_failure: true](#allow_failure) 并且被认为是可选的。可选手工流水线任务的状态并不影响整体的流水线状态。即使所有手动流水线任务都失败，流水线也可以成功运行。
阻塞手动作业会在以下阶段停止管道的进一步执行
工作被定义。要让管道继续运行，请单击 **{play}** (play) on
阻塞手工作业。
使用 [管道成功时合并](../../user/project/merge_requests/merge_when_pipeline_succeeds.md) 合并项目中的请求 - **阻塞**：要将手动流水线任务设置为阻塞，请将 `allow_failure: false` 添加到其配置中。阻塞的手动流水线任务会在其被定义的下一阶段停止流水线的进一步执行。要让流水线继续运行，请单击阻塞手动流水线任务上的 **{play}** 按钮。
enabled 不能与阻塞的管道合并。阻塞的管道显示状态
**阻止**。
当您使用 [`rules:`](#rules) 时，`allow_failure` 默认为 `false`，包括手动作业。 项目中设置了流水线成功时合并的合并请求在有流水线阻塞的情况下无法合并。阻塞的流水线显示 **阻塞** 的状态。
要触发手动作业，用户必须具有合并到指定分支的权限。 当你使用 [`rules:`](#rules) 时，`allow_failure` 的值默认为 `false`，包括手动流水线任务。
您可以使用 [protected branch](../../user/project/protected_branches.md) 来更严格
[保护手动部署](#protecting-manual-jobs) 不被未经授权的用户运行。
在 [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/201938) 及更高版本中，您 要触发手动流水线任务，用户必须具有合并到指定分支的权限。你可以使用 [保护分支](/docs/user/project/protected-branch) 来更限制未经授权的用户运行[保护手动部署](#protecting-manual-jobs)。
可以在与 [`trigger`](#trigger) 相同的作业中使用 `when:manual`。在 GitLab 13.4 和
早些时候，将它们一起使用会导致错误 `jobs:#{job-name} when should be on_success, on_failure or always`。
##### 保护手工作业 **(PREMIUM)** <!-->
##### 保护手工流水线任务[](#protecting-manual-jobs)
使用[受保护的环境](../environments/protected_environments.md) 使用受保护的环境定义授权运行手动流水线任务的用户列表。你只能授权与受保护环境关联以触发手动流水线任务的用户，这样做的目的是：
定义授权运行手动作业的用户列表。您只能授权
与受保护环境关联以触发手动作业的用户，这可以：
- 更精确地限制可以部署到环境的人员。 - 更精确地限制可以部署到环境的人员。
- 阻止管道，直到获得批准的用户“批准”它。 - 阻止流水线，直到获得批准的用户“批准”它。
要保护手动作业： 要保护手动流水线任务：
1. 为作业添加一个 `environment`。例如： 1. 为流水线任务添加一个 `environment`。例如：
```yaml ```yaml
deploy_prod: deploy_prod:
阶段：部署 stage: deploy
脚本： script:
- echo "部署到生产服务器" - echo "Deploy to production server"
环境： environment:
名称：生产 name: production
网址：https://example.com url: https://example.com
时间：手动 when: manual
只要： only:
- 主要的 - main
`` ```
1.在[受保护的环境设置](../environments/protected_environments.md#protecting-environments)中， 2. 在受保护的环境设置中，选择环境（本例中为 `production`）并添加用户、角色或组到被授权触发手动流水线任务到 **Allowed to Deploy** 列表。只有那些在此列表可以触发此手动流水线任务。
选择环境（本例中为“生产”）并添加用户、角色或组
被授权触发手动作业到 **Allowed to Deploy** 列表。只有那些在 你可以使用具有阻止手动流水线任务的受保护环境来获得用户列表允许批准以后的流水线阶段。将 `allow_failure: false` 添加到受保护的手动流水线任务和流水线的下一阶段仅在手动流水线任务被由授权用户触发后运行。
此列表可以触发此手动作业，以及 GitLab 管理员 <!-->
谁总是能够使用受保护的环境。
#### `when:delayed`[](#whendelayed)
您可以使用具有阻止手动作业的受保护环境来获得用户列表
允许批准以后的管道阶段。将 `allow_failure: false` 添加到受保护的 使用 `when: delay` 在等待期后执行脚本，或者如果你想避免流水线任务立即进入 `pending` 状态。
手动作业和管道的下一阶段仅在手动作业被触发后运行
由授权用户。 你可以使用 `start_in` 关键字设置时间范围。`start_in` 的值是以秒为单位的时间范围，除非提供了时间单位。`start_in` 必须小于或等于 1 周。有效值的示例包括：
####`何时：延迟`
> [介绍](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51352) 在 GitLab 11.4 中。
使用 `when: delay` 在等待期后执行脚本，或者如果你想避免
作业立即进入“待处理”状态。
您可以使用“start_in”关键字设置时间段。`start_in` 的值是以秒为单位的经过时间，除非一个单位是
假如。`start_in` 必须小于或等于 1 周。有效值的示例包括：
- `'5'` - `'5'`
- `5秒` - `5 seconds`
- `30分钟` - `30 minutes`
- `1天` - `1 day`
- `1周` - `1 week`
当阶段包含延迟作业时，管道在延迟作业完成之前不会进行。 > Delay 设置的时间不计算在流水线用量中，但默认流水线超时时间为60分钟，建议不要设置过长，否则会因为超时导致流水线的失败。
您可以使用此关键字在不同阶段之间插入延迟。
延迟作业的计时器在前一阶段完成后立即启动。 当阶段包含延迟流水线任务时，流水线在延迟流水线任务完成之前不会进行。你可以使用此关键字在不同阶段之间插入延迟。
与其他类型的作业类似，除非前一阶段通过，否则延迟作业的计时器不会启动。
以下示例创建一个名为“timed rollout 10%”的作业，该作业在前一阶段完成 30 分钟后执行： 延迟流水线任务的计时器在前一阶段完成后立即启动。与其他类型的流水线任务类似，除非前一阶段通过，否则延迟流水线任务的计时器不会启动。
以下示例创建了一个名为 `timed rollout 10%` 的流水线任务，该流水线任务在前一阶段完成 30 分钟后执行：
```yaml ```yaml
定时推出 10%： timed rollout 10%:
阶段：部署 stage: deploy
脚本：echo '推出 10% ...' script: echo 'Rolling out 10% ...'
时间：延迟 when: delayed
start_in：30 分钟 start_in: 30 minutes
`` ```
要停止延迟作业的活动计时器，请单击 **{time-out}** (**Unschedule**) 按钮。 要停止延迟流水线任务的活动计时器，请单击 **{time-out}** (**Unschedule**) 按钮。之后，将无法再安排此流水线任务自动运行。但是，你可以手动执行流水线任务。
无法再安排此作业自动运行。但是，您可以手动执行作业。
要立即开始延迟作业，请单击**播放** 按钮。 要立即开始延迟流水线任务，请单击 **play** 按钮。很快，Runner 将接手并开始工作。
很快，GitLab Runner 接手并开始工作。
###`环境` ### `environment`[](#environment)
使用 `environment` 定义流水线任务部署到的环境。
使用 `environment` 定义作业部署到的 [环境](../environments/index.md)。
例如： 例如：
```yaml ```yaml
部署到生产： deploy to production:
阶段：部署 stage: deploy
脚本：git push production HEAD：main script: git push production HEAD:main
环境：生产 environment: production
`` ```
您可以使用以下方法为 `environment` 关键字赋值： 你可以使用以下方法为 `environment` 关键字进行赋值：
- 纯文本，如 `production`。 - 纯文本，如 `production`。
- 变量，包括 CI/CD 变量、预定义、安全或变量 - 变量，包括 CI/CD 变量、预定义、安全或变量，在`.codechina-ci.yml` 文件中定义。
在`.gitlab-ci.yml` 文件中定义。
您不能使用在 `script` 部分中定义的变量。 你不能使用在 `script` 部分中定义的变量。
如果您指定了一个 `environment` 并且不存在具有该名称的环境， 如果你指定了一个 `environment` 且不存在具有该名称的环境，就会新建这个环境。
创造了一个环境。
####`环境：名称` #### `environment:name`[](#environmentname)
为 [environment](../environments/index.md) 设置名称。例如： 为 `environment` 设置名称。例如：
```yaml ```yaml
部署到生产： deploy to production:
阶段：部署 stage: deploy
脚本：git push production HEAD：main script: git push production HEAD:main
环境： environment:
名称：生产 name: production
`` ```
常见的环境名称是 `qa`、`staging` 和 `production`，但您可以使用任何 常见的环境名称是 `qa`、`staging` 和 `production`，但你可以使用任何你想要的名字。
你想要的名字。
您可以使用以下命令为 `name` 关键字赋值： 你可以使用以下命令为 `name` 关键字进行赋值：
- 纯文本，如`staging`。 - 纯文本，如`staging`。
- 变量，包括 CI/CD 变量、预定义、安全或变量 - 变量，包括在`.codechina-ci.yml` 文件中定义的 CI/CD 变量、预定义、安全或变量。
在`.gitlab-ci.yml` 文件中定义。
您不能使用在 `script` 部分中定义的变量。 你不能使用在 `script` 部分中定义的变量。
环境 `name` 可以包含： 环境 `name` 可以包含：
- 信件 - Letters
- 数字 - Digits
- 空间 - Spaces
-`-` - `-`
-`_` - `_`
-`/` - `/`
-`$` - `$`
-`{` - `{`
-`}` - `}`
####`环境：url` #### `environment:url`[](#environmenturl)
为 [environment](../environments/index.md) 设置 URL。例如： 为 `environment` 设置 URL。例如：
```yaml ```yaml
部署到生产： deploy to production:
阶段：部署 stage: deploy
脚本：git push production HEAD：main script: git push production HEAD:main
环境： environment:
名称：生产 name: production
网址：https://prod.example.com url: https://prod.example.com
`` ```
作业完成后，您可以使用合并请求中的按钮访问 URL， 流水线任务完成后，你可以使用合并请求中的按钮访问 URL，环境或部署页面。
环境或部署页面。
您可以使用以下方法为 `url` 关键字赋值： 你可以使用以下方法为 `url` 关键字进行赋值：
- 纯文本，如`https://prod.example.com`。 - 纯文本，如`https://prod.example.com`。
- 变量，包括 CI/CD 变量、预定义、安全或变量 - 变量，包括在`.codechina-ci.yml` 文件中定义 CI/CD 变量、预定义、安全或变量。
在`.gitlab-ci.yml` 文件中定义。
您不能使用在 `script` 部分中定义的变量。 你不能使用在 `script` 部分中定义的变量。
####`环境：on_stop` #### `environment:on_stop`
关闭（停止）环境可以使用 `on_stop` 关键字来实现 关闭（停止）环境可以在 `environment` 下定义使用 `on_stop` 关键字来实现。它声明了一个不同的流水线任务来关闭环境。
在“环境”下定义。它声明了一个不同的工作来关闭
环境。
阅读“environment:action”部分的示例。 阅读 `environment:action` 部分的示例。
####`环境：动作` #### `environment:action`[](#environmentaction)
使用 `action` 关键字来指定准备、启动或停止环境的作业。 使用 `action` 关键字来指定准备、启动或停止环境的流水线任务。
| **价值** | **说明** | | **值** | **说明** |
|-----------|------------------------------------ -------------------------------------------------- -------------------------------------------------- ---------------| |-----------|------------------------------------ -------------------------------------------------- -------------------------------------------------- ---------------|
| `开始` | 默认值。表示作业启动环境。部署是在作业启动后创建的 | | `start` | 默认值。表示流水线任务启动环境。部署是在流水线任务启动后创建的 |
| `准备` | 表示作业只准备环境。它不会触发部署。[阅读有关准备环境的更多信息](../environments/index.md#prepare-an-environment-without-creating-a-deployment) | | `prepare` | 表示流水线任务只准备环境。它不会触发部署 |
| `停止` | 表示作业停止部署。请参阅下面的示例 | | `stop` | 表示流水线任务停止部署。请参阅下面的示例 |
举个例子： 举个例子：
```yaml ```yaml
评论应用： review_app:
阶段：部署 stage: deploy
脚本：制作部署应用程序 script: make deploy-app
环境： environment:
名称：评论/$CI_COMMIT_REF_NAME name: review/$CI_COMMIT_REF_NAME
网址：https://$CI_ENVIRONMENT_SLUG.example.com url: https://$CI_ENVIRONMENT_SLUG.example.com
on_stop：stop_review_app on_stop: stop_review_app
stop_review_app: stop_review_app:
阶段：部署 stage: deploy
变量： variables:
GIT_STRATEGY：无 GIT_STRATEGY: none
脚本：make delete-app script: make delete-app
时间：手动 when: manual
环境： environment:
名称：评论/$CI_COMMIT_REF_NAME name: review/$CI_COMMIT_REF_NAME
行动：停止 action: stop
`` ```
在上面的例子中，`review_app` 作业部署到 `review` 在上面的例子中，`review_app` 流水线任务部署到 `review` 环境。在 `on_stop` 下列出了一个新的 `stop_review_app` 流水线任务。在 `review_app` 流水线任务完成后，它会基于 `when` 下定义的内容触发 `stop_review_app` 流水线任务。在这个例子中，它被设置为 `manual`，所以它需要一个 [manual action](#whenmanual) 并从 UI 中手动运行。
环境。在“on_stop”下列出了一个新的“stop_review_app”作业。
在“review_app”作业完成后，它会触发
`stop_review_app` 作业基于 `when` 下定义的内容。在这种情况下，
它被设置为 `manual`，所以它需要一个 [manual action](#whenmanual) from
要运行的 GitLab UI。
同样在示例中，`GIT_STRATEGY` 设置为 `none`。如果 在示例中，`GIT_STRATEGY` 设置为 `none`。如果 `stop_review_app` 流水线任务是自动触发，删除分支后，运行程序不会尝试检查代码。
`stop_review_app` 作业是[自动触发](../environments/index.md#stopping-an-environment)，
删除分支后，运行程序不会尝试检查代码。
该示例还覆盖了全局变量。如果您的“停止”“环境”工作取决于 该示例还覆盖了全局变量。如果你的 `stop` `environment` 流水线任务取决于在全局变量上，在设置 `GIT_STRATEGY` 时使用 [anchor variables](#yaml-anchors-for-variables)在不覆盖全局变量的情况下更改流水线任务。
在全局变量上，在设置 `GIT_STRATEGY` 时使用 [anchor variables](#yaml-anchors-for-variables)
在不覆盖全局变量的情况下更改作业。
`stop_review_app` 作业**需要**定义以下关键字： `stop_review_app` 流水线任务**需要**定义以下关键字：
- `when`，定义于： - `when`，定义于：
- [工作级别](#when)。 - [流水线任务级别](#when)。
- [在规则子句中](#rules)。如果你使用 `rules:` 和 `when: manual`，你应该 - [在规则条款中](#rules)。如果你使用 `rules:` 和 `when: manual`，你还应该设置 [`allow_failure: true`](#allow_failure) 以便可以完成流水线即使流水线任务没有运行。
还设置 [`allow_failure: true`](#allow_failure) 以便管道可以完成 - `environment:name`
即使作业没有运行。 - `environment:action`
-`环境：名称`
-`环境：动作`
此外，两个工作都应该有匹配的 [`rules`](#only--except) 此外，每个流水线任务都应该有匹配的 [`rules`](#only--except) 或 [`only/except`](#only--except) 配置。
或 [`only/except`](#only--except) 配置。
在上面的示例中，如果配置不相同： 在上面的示例中，如果配置不相同：
- `stop_review_app` 作业可能不会包含在包含 `review_app` 作业的所有管道中。 - `stop_review_app` 流水线任务可能不会包含在所有引用了`review_app` 流水线任务的流水线中。
- 无法触发 `action: stop` 来自动停止环境。 - 无法触发 `action: stop` 来自动停止环境。
####`环境：auto_stop_in` #### `environment:auto_stop_in`
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/20956) 在 GitLab 12.8 中。 `auto_stop_in` 关键字用于指定环境的生命周期，当过期时，系统会自动停止它们。
`auto_stop_in` 关键字用于指定环境的生命周期，
当过期时，GitLab 会自动停止它们。
例如， 例如，
```yaml ```yaml
评论应用： review_app:
脚本：deploy-review-app script: deploy-review-app
环境： environment:
名称：评论/$CI_COMMIT_REF_NAME name: review/$CI_COMMIT_REF_NAME
auto_stop_in：1 天 auto_stop_in: 1 day
`` ```
当为“review_app”创建环境时，环境的生命周期设置为“1 天”。
每次部署审查应用程序时，该生命周期也会重置为“1 天”。
有关更多信息，请参阅
[环境自动停止文档](../environments/index.md#stop-an-environment-after-a-certain-time-period)
####`环境：kubernetes` 当为 `review_app` 创建环境时，环境的生命周期设置为 “1 天”。每次部署审查应用程序时，该生命周期也会重置为 “1 天”。
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/27630) 在 GitLab 12.6 中。 #### `environment:kubernetes`
使用 `kubernetes` 关键字将部署配置为 使用 `kubernetes` 关键字将部署配置为与你的项目相关联的 `Kubernetes cluster` 。
[Kubernetes cluster](../../user/project/clusters/index.md) 与您的项目相关联。
例如： 例如：
```yaml ```yaml
部署： deploy:
阶段：部署 stage: deploy
脚本：制作部署应用程序 script: make deploy-app
环境： environment:
名称：生产 name: production
Kubernetes： kubernetes:
命名空间：生产 namespace: production
`` ```
此配置设置了 `deploy` 作业以部署到 `production`
环境，使用 `production`
[Kubernetes 命名空间](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)。
有关更多信息，请参阅
[`kubernetes` 的可用设置](../environments/index.md#configure-kubernetes-deployments)。
笔记： 此配置使用 `production` [Kubernetes 命名空间](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)，将 `deploy` 流水线任务部署到 `production`环境。
Kubernetes 集群不支持 Kubernetes 配置
[由 GitLab 管理](../../user/project/clusters/index.md#gitlab-managed-clusters)。
要了解对 GitLab 管理的集群的支持进展，请参阅
[相关问题](https://gitlab.com/gitlab-org/gitlab/-/issues/38054)。
####`环境：deployment_tier` > Kubernetes 配置不支持由 GitLab 管理的 Kubernetes cluster。
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/300741) 在 GitLab 13.10 中。 #### `environment:deployment_tier`
使用 `deployment_tier` 关键字指定部署环境的层级： 使用 `deployment_tier` 关键字指定部署环境的层级：
```yaml ```yaml
部署： deploy:
脚本：回声 script: echo
环境： environment:
名称：客户门户 name: customer-portal
部署层：生产 deployment_tier: production
`` ```
想要查询更多的信息，
请参阅[环境的部署层](../environments/index.md#deployment-tier-of-environments)。
#### 动态环境 #### 动态环境
使用 CI/CD [variables](../variables/README.md) 动态命名环境。 使用 CI/CD [变量](/docs/ci/variables) 来动态命名环境。
例如： 例如：
```yaml ```yaml
部署为审查应用程序： deploy as review app:
阶段：部署 stage: deploy
脚本：进行部署 script: make deploy
环境： environment:
名称：评论/$CI_COMMIT_REF_NAME name: review/$CI_COMMIT_REF_NAME
网址：https://$CI_ENVIRONMENT_SLUG.example.com/ url: https://$CI_ENVIRONMENT_SLUG.example.com/
`` ```
`deploy as review app` 作业被标记为动态部署
创建 `review/$CI_COMMIT_REF_NAME` 环境。`$CI_COMMIT_REF_NAME`
是由跑步者设置的 [CI/CD 变量](../variables/README.md)。这
`$CI_ENVIRONMENT_SLUG` 变量基于环境名称，但适用
用于包含在 URL 中。如果 `deploy as review app` 作业在名为的分支中运行
`pow`，这个环境可以通过像 `https://review-pow.example.com/` 这样的 URL 访问。
常见的用例是为分支创建动态环境并使用它们
作为审查应用程序。您可以在以下位置查看使用 Review Apps 的示例
<https://gitlab.com/gitlab-examples/review-apps-nginx/>。
###`缓存` 在这个例子中，`deploy as review app` 流水线任务被标记为动态部署创建 `review/$CI_COMMIT_REF_NAME` 环境。`$CI_COMMIT_REF_NAME` 是由 Runner 设置的 [CI/CD 变量](/docs/ci/variables)。`$CI_ENVIRONMENT_SLUG` 变量基于环境名称，可适用于 URL 中。如果 `deploy as review app` 流水线任务在名为 `pow` 的分支中运行，则这个环境可以通过 `https://review-pow.example.com/` 这样的 URL 访问。
使用 `cache` 指定要使用的文件和目录列表 常见的用法是为分支创建动态环境并使用它们作为审查应用程序。你可以在以下位置查看使用 Review Apps 的示例 <https://gitlab.com/gitlab-examples/review-apps-nginx/>。
作业之间的缓存。您只能使用本地工作副本中的路径。
如果在作业范围之外定义了 `cache`，则设置它 ### `cache`[](#cache)
全局和所有作业都使用该配置。
缓存在管道和作业之间共享。缓存在 [artifacts](#artifacts) 之前恢复。 使用 `cache` 指定流水线任务之间要使用的文件和目录列表的缓存。你只能使用本地工作副本中的路径。
阅读缓存的工作原理并在 如果在流水线任务范围之外定义了 `cache`，则它会是一个全局设置并且所有流水线任务都将使用该配置。
[缓存依赖文档](../caching/index.md)。
####`缓存：路径` 缓存在流水线和流水线任务之间共享。缓存在 [artifacts](#artifacts) 之前恢复。
使用 `paths` 指令选择要缓存的文件或目录。路径 #### ``cache:paths``
相对于项目目录 (`$CI_PROJECT_DIR`)，不能直接链接到项目目录之外。
您可以使用使用 [glob](https://en.wikipedia.org/wiki/Glob_(programming)) 的通配符
模式和：
- 在 [GitLab Runner 13.0](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2620) 及更高版本中， 使用 `paths` 指令选择要缓存的文件或目录。路径相对于项目目录 (`$CI_PROJECT_DIR`)，不能直接链接到项目目录之外。你可以使用使用 [glob](https://en.wikipedia.org/wiki/Glob_(programming)) 的通配符模式。
[`doublestar.Glob`](https://pkg.go.dev/github.com/bmatcuk/doublestar@v1.2.2?tab=doc#Match)。
- 在 GitLab Runner 12.10 及更早版本中，
[`filepath.Match`](https://pkg.go.dev/path/filepath#Match)。
缓存`binaries`中以`.apk`和`.config`文件结尾的所有文件： 缓存 `binaries` 中以 `.apk` 文件结尾和 `.config`文件结尾的所有文件：
```yaml ```yaml
规格： rspec:
脚本：测试 script: test
缓存： cache:
路径： paths:
- 二进制文件/*.apk - binaries/*.apk
- .config - .config
`` ```
本地定义的缓存覆盖全局定义的选项。以下`rspec` 本地定义的缓存覆盖全局定义的选项。以下例子中 `rspec` 流水线任务只缓存 `binaries/`：
作业只缓存 `binaries/`：
```yaml ```yaml
缓存： cache:
路径： paths:
- 我的文件 - my/files
规格： rspec:
脚本：测试 script: test
缓存： cache:
关键：rspec key: rspec
路径： paths:
- 二进制文件/ - binaries/
`` ```
缓存在作业之间共享，因此如果您使用不同的 缓存在流水线任务之间是共享的，因此如果你使用不同的不同流水线任务的路径，你还应该设置不同的 `cache:key`，否则缓存内容可能会被覆盖。
不同作业的路径，您还应该设置不同的 `cache:key`。
否则缓存内容可能会被覆盖。
####`缓存：密钥` #### `cache:key`
`key` 关键字定义了作业之间缓存的亲和性。 `key` 关键字定义了流水线任务之间缓存的亲和性。你可以为所有流水线任务使用一个缓存，或者为流水线任务生成缓存，或为每个分支生成缓存，或任何其他适合你工作流程的方式来生成缓存。你可以微调缓存，包括在不同流水线任务甚至不同分支之间缓存数据。
您可以为所有作业使用一个缓存，每个作业缓存，每个分支缓存，
或任何其他适合您工作流程的方式。您可以微调缓存，
包括在不同作业甚至不同分支之间缓存数据。
`cache:key` 变量可以使用任何 `cache:key` 变量可以使用任何[预定义变量](/docs/ci/variables)。如果不是
[预定义变量](../variables/README.md)。默认键，如果不是 设置，默认值只是字面上的 `default`，这意味着默认情况下一切缓存都在流水线和流水线任务之间共享。
设置，只是字面上的“默认”，这意味着一切都在之间共享
默认情况下管道和作业。
例如，要启用每个分支缓存： 比如，要为每个分支启用缓存：
```yaml ```yaml
缓存： cache:
键：“$CI_COMMIT_REF_SLUG” key: "$CI_COMMIT_REF_SLUG"
路径： paths:
- 二进制文件/ - binaries/
`` ```
如果您使用 **Windows Batch** 运行您的 shell 脚本，则需要替换 如果你使用 **Windows Batch** 运行你的 shell 脚本，则需要替换 `$` 和 `%`：
`$` 和 `%`：
```yaml ```yaml
缓存： cache:
键：“%CI_COMMIT_REF_SLUG%” key: "%CI_COMMIT_REF_SLUG%"
路径： paths:
- 二进制文件/ - binaries/
`` ```
`cache:key` 变量不能包含 `/` 字符或等效字符
URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。
如果未找到指定的 `cache:key`，您可以指定 [fallback cache key](#fallback-cache-key) 使用。 `cache:key` 变量不能包含 `/` 字符或等效字符 URI 编码的 `%2F`，也禁止仅由点（`.`、`%2E`）组成的值。
#####多个缓存 如果未找到指定的 `cache:key`，你可以指定使用 [fallback 缓存键](#fallback-cache-key) 。
> - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/32814) 在 GitLab 13.10 中。 ##### 多个缓存
> - [功能标记已删除](https://gitlab.com/gitlab-org/gitlab/-/issues/321877)，在 GitLab 13.12 中。
您最多可以有四个缓存： 你最多可以有四个缓存：
```yaml ```yaml
测试工作： test-job:
阶段：构建 stage: build
缓存： cache:
- 钥匙： - key:
文件： files:
- Gemfile.lock - Gemfile.lock
路径： paths:
- 供应商/红宝石 - vendor/ruby
- 钥匙： - key:
文件： files:
- 纱线锁 - yarn.lock
路径： paths:
- .纱线缓存/ - .yarn-cache/
脚本： script:
- 捆绑安装 --path=vendor - bundle install --path=vendor
- 纱线安装 --cache-folder .yarn-cache - yarn install --cache-folder .yarn-cache
- 回声运行测试... - echo Run tests...
`` ```
如果多个缓存与一个 [Fallback 缓存键](#fallback-cache-key) 组合在一起， 如果多个缓存与一个 [Fallback 缓存键](#fallback-cache-key) 组合在一起，如果未找到多个缓存，则多次获取回退。
如果未找到多个缓存，则多次获取回退。
#### 回退缓存键 #### 回退缓存键
> [介绍](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1534) 在 GitLab Runner 13.4 中。 你可以使用`$CI_COMMIT_REF_SLUG` [variable](#variables) 来指定你的[`cache:key`](#cachekey)。例如，如果你的 `$CI_COMMIT_REF_SLUG` 是 `test` 你可以设置一个流水线任务
下载标有 `test` 的缓存。
你可以使用`$CI_COMMIT_REF_SLUG` [variable](#variables) 来指定你的[`cache:key`](#cachekey)。
例如，如果你的 `$CI_COMMIT_REF_SLUG` 是 `test` 你可以设置一个作业
下载标有“test”的缓存。
如果没有找到带有这个标签的缓存，你可以使用`CACHE_FALLBACK_KEY`来 如果没有找到带有这个标签的缓存，也就是缓存不存在时，你可以指定使用`CACHE_FALLBACK_KEY`。
指定缓存不存在时使用。
在以下示例中，如果未找到 `$CI_COMMIT_REF_SLUG`，则作业使用定义的键 在下面的例子中，如果未找到 `$CI_COMMIT_REF_SLUG`，则流水线任务使用通过`CACHE_FALLBACK_KEY`变量定义的键：
通过`CACHE_FALLBACK_KEY`变量：
```yaml ```yaml
变量： variables:
CACHE_FALLBACK_KEY：回退键 CACHE_FALLBACK_KEY: fallback-key
缓存：
键：“$CI_COMMIT_REF_SLUG”
路径：
- 二进制文件/
``
#####`缓存：密钥：文件` cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- binaries/
```
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/18986) 在 GitLab v12.5 中。 ##### `cache:key:files`
`cache:key:files` 关键字扩展了 `cache:key` 功能，使其更容易 `cache:key:files` 关键字扩展了 `cache:key` 功能，使其可以更容易重用一些缓存，并减少重建它们的频率，从而加快后续流水线运行。
重用一些缓存，并减少重建它们的频率，从而加快后续管道
运行。
当您包含 `cache:key:files` 时，您还必须列出用于生成密钥的项目文件，最多两个文件。 当你引用了 `cache:key:files` 时，你还必须列出用于生成密钥的项目文件（最多两个文件）。缓存 `key` 是根据指定文件的最近提交（最多两个，如果列出了两个文件）计算的 SHA 校验的。如果指定文件在任何提交中都没有更改，那么后退键是 `default`。
缓存“key”是根据最近提交计算的 SHA 校验和（最多两个，如果列出了两个文件）
改变了给定的文件。如果在任何提交中都没有更改任何文件，
后备键是`default`。
```yaml ```yaml
缓存： cache:
钥匙： key:
文件： files:
- Gemfile.lock - Gemfile.lock
- 包.json - package.json
路径： paths:
- 供应商/红宝石 - vendor/ruby
- 节点模块 - node_modules
`` ```
此示例为 Ruby 和 Node.js 依赖项创建缓存
与当前版本的 `Gemfile.lock` 和 `package.json` 文件相关联。每当其中之一
这些文件发生变化，计算新的缓存键并创建新的缓存。任何未来
作业运行使用相同的 `Gemfile.lock` 和 `package.json` 和 `cache:key:files`
使用新的缓存，而不是重建依赖项。
#####`缓存：键：前缀` 这个例子中，为 `Ruby` 和 `Node.js` 依赖项创建缓存，并与当前版本的 `Gemfile.lock` 和 `package.json` 文件相关联。每当这些文件发生变化时，会计算新的缓存键并创建新的缓存。未来任何流水线任务运行使用了由相同的 `Gemfile.lock` 和 `package.json` 的 `cache:key:files` 都使用新的缓存，而不是重建这些依赖项。
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/18986) 在 GitLab v12.5 中。 ##### `cache:key:prefix`
当您想将前缀与为 `cache:key:files` 计算的 SHA 结合起来时， 当你想将前缀与通过 `cache:key:files` 计算的 SHA 结合起来时，将 `prefix` 关键字与 `key:files` 一起使用。例如，如果添加了 `test` 作为 `prefix`，结果 key 为`test-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5`。如果给定文件在任何提交中都没有更改，则会在 `default` 上添加前缀，因此示例中的 key 是 `test-default`。
将 `prefix` 关键字与 `key:files` 一起使用。
例如，如果添加 `test` 的 `prefix`，结果键为：`test-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5`。
如果在任何提交中都没有更改任何文件，则将前缀添加到 `default`，因此
示例中的关键是“test-default”。
像`cache:key`一样，`prefix`可以使用任何[预定义变量](../variables/README.md)， 像`cache:key`一样，`prefix`可以使用任何[预定义变量](/docs/ci/variables)，但不能包括：
但不能包括：
- `/` 字符（或等效的 URI 编码的 `%2F`） - `/` 字符（或等效的 URI 编码的 `%2F`）
- 仅由 `.` 组成的值（或等效的 URI 编码的 `%2E`） - 仅由 `.` 组成的值（或等效的 URI 编码的 `%2E`）
```yaml ```yaml
缓存： cache:
钥匙： key:
文件： files:
- Gemfile.lock - Gemfile.lock
前缀：${CI_JOB_NAME} prefix: ${CI_JOB_NAME}
路径： paths:
- 供应商/红宝石 - vendor/ruby
规格： rspec:
脚本： script:
- 捆绑执行 rspec - bundle exec rspec
`` ```
例如，添加`$CI_JOB_NAME`的`prefix` 例如，添加了 `$CI_JOB_NAME` 的 `prefix` 后密钥看起来像：`rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5`，并且流水线任务缓存在不同的分支之间共享。如果某个分支中的 `Gemfile.lock` 发生变化，则该分支对 `cache:key:files` 有一个新的 SHA 校验并生成一个新的缓存 key，并为该键创建一个新的缓存。如果没有找到 `Gemfile.lock`，则将前缀添加到 `default`，因此示例中的 key 会是 `rspec-default`。
导致密钥看起来像：`rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5`和
作业缓存在不同的分支之间共享。如果分支发生变化
`Gemfile.lock`，该分支对 `cache:key:files` 有一个新的 SHA 校验和。一个新的缓存键
生成，并为该键创建一个新的缓存。
如果没有找到`Gemfile.lock`，则将前缀添加到
`default`，因此示例中的键是 `rspec-default`。
####`缓存：未跟踪` #### `cache:untracked`
设置 `untracked: true` 以缓存 Git 中未跟踪的所有文件 设置 `untracked: true` 以缓存 Git 中未跟踪的所有文件存储库：
存储库：
```yaml ```yaml
规格： rspec:
脚本：测试 script: test
缓存： cache:
未追踪：真实 untracked: true
`` ```
缓存所有 Git 未跟踪文件和 `binaries` 中的文件： 缓存所有 Git 未跟踪文件和 `binaries` 中的文件：
```yaml ```yaml
规格： rspec:
脚本：测试 script: test
缓存： cache:
未追踪：真实 untracked: true
路径： paths:
- 二进制文件/ - binaries/
`` ```
####`缓存：当`
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/18969) 在 GitLab 13.5 和 GitLab Runner v13.5.0 中。 #### `cache:when`
`cache:when` 根据作业的状态定义何时保存缓存。你可以 `cache:when` 根据流水线任务的状态来定义何时保存缓存。你可以将 `cache:when` 设置为：
将 `cache:when` 设置为：
- `on_success`（默认）：仅在作业成功时保存缓存。 - `on_success`（默认）：仅在流水线任务成功时保存缓存。
- `on_failure`：仅在作业失败时保存缓存。 - `on_failure`：仅在流水线任务失败时保存缓存。
- `always`：始终保存缓存。 - `always`：始终保存缓存。
例如，无论作业是否成功，都要存储缓存： 例如，无论流水线任务是否成功，都要存储缓存：
```yaml ```yaml
规格： rspec:
脚本：rspec script: rspec
缓存： cache:
路径： paths:
- rspec/ - rspec/
什么时候：'总是' when: 'always'
`` ```
####`缓存：策略` #### `cache:policy`
缓存作业的默认行为是在开始时下载文件 缓存流水线任务的默认行为是在开始执行时下载文件，并在最后重新上传它们。任何流水线任务的更改将保留以供将来运行。这种行为被称为`pull-push`缓存政策。
执行，并在最后重新上传它们。任何更改
作业将保留以供将来运行。这种行为被称为`pull-push`缓存
政策。
如果您知道该作业不会更改缓存文件，则可以跳过上传步骤 如果你知道该流水线任务不会更改缓存文件，则可以跳过上传步骤，通过在流水线任务中设置 `policy: pull`。可以在较早的阶段中添加普通缓存流水线任务以确保缓存保持更新：
通过在作业规范中设置`policy: pull`。可以添加普通缓存
作业在较早的阶段以确保缓存不时更新：
```yaml ```yaml
阶段： stages:
- 设置 - setup
- 测试 - test
准备：
阶段：设置
缓存：
关键：宝石
路径：
- 供应商/捆绑
脚本：
- 捆绑安装 --deployment
规格： prepare:
阶段：测试 stage: setup
缓存： cache:
关键：宝石 key: gems
路径： paths:
- 供应商/捆绑 - vendor/bundle
政策：拉 script:
脚本： - bundle install --deployment
- 捆绑执行 rspec ...
``
当您有许多使用缓存并行执行的作业时，请使用 `pull` 策略。这 rspec:
策略加速作业执行并减少缓存服务器上的负载。 stage: test
cache:
key: gems
paths:
- vendor/bundle
policy: pull
script:
- bundle exec rspec ...
```
如果您的作业无条件地重新创建缓存 当你有许多使用缓存并行执行的流水线任务时，请使用 `pull` 策略。该策略可以加速流水线任务执行并减少缓存服务器上的负载。
参考之前的内容，可以跳过下载步骤。
为此，请将 `policy: push` 添加到作业中。
###`神器` 如果你的流水线任务无条件地重新创建缓存，参考之前的内容，可以跳过下载步骤。为此，可以将 `policy: push` 添加到流水线任务中。
使用 `artifacts` 指定文件和目录列表 ### `artifacts`[](#artifacts)
当它[成功、失败或总是](#artifactswhen) 时附加到作业。
作业完成后，工件将发送到 GitLab。他们是 使用 `artifacts` 指定文件和目录列表。当它 [succeeds, fails, or always](#artifactswhen) 时附加到流水线任务中。
如果大小不合适，可以在 GitLab UI 中下载
大于 [最大工件大小](../../user/gitlab_com/index.md#gitlab-cicd)。
默认情况下，后期的作业会自动下载所有创建的工件 流水线任务完成后， `artifacts`将发送到 codechina。如果他们的大小不超过 500M (目前设置的最大 `artifacts` 大小)，就可以在 UI 中进行下载。
通过早期阶段的工作。您可以使用以下命令控制作业中的工件下载行为
[`dependencies`](#dependencies)。
使用 [`needs`](#artifact-downloads-with-needs) 关键字时，作业只能下载 默认情况下，后期的流水线任务会自动下载所有通过早期阶段的流水线任务创建的 `artifacts`。你可以使用 [`dependencies`](#dependencies) 命令控制流水线任务中的 `artifacts`下载行为。
来自在 `needs` 配置中定义的作业的工件。
默认情况下，仅为成功的作业收集作业工件，并且 使用 [`needs`](#artifact-downloads-with-needs) 关键字时，流水线任务只能下载来自在 `needs` 配置中定义的流水线任务的 `artifacts`。
在 [caches](#cache) 之后恢复工件。
[阅读有关工件的更多信息](../pipelines/job_artifacts.md)。 默认情况下，仅为成功的流水线任务收集流水线任务 `artifacts`，并且在 [caches](#cache) 之后恢复 `artifacts`。
####`依赖关系` #### `dependencies`
默认情况下，前一阶段的所有“工件” 默认情况下，前一阶段的所有 `artifacts` 将传递给每个流水线任务。但是，你可以使用 `dependencies` 关键字来定义要从中获取 `artifacts` 的有限流水线任务列表。你还可以设置一个完全不下载任何 `artifacts`流水线任务。
传递给每个作业。但是，您可以使用 `dependencies` 关键字来
定义要从中获取工件的有限作业列表。您还可以设置一个作业来完全不下载任何工件。
要使用此功能，请在作业上下文中定义 `dependencies` 并通过 要使用此功能，请在流水线任务上下文中定义 `dependencies` 并提供一个应从先前流水线任务中下载 `artifacts`的流水线任务列表。
应从中下载工件的所有先前作业的列表。
您可以从在当前阶段之前执行的阶段定义作业。 你可以在当前阶段之前执行的阶段定义流水线任务。如果你从当前或即将到来的阶段定义流水线任务，则会发生错误。
如果您从当前或即将到来的阶段定义作业，则会发生错误。
要防止作业下载工件，请定义一个空数组。 要防止流水线任务下载 `artifacts`，请定义一个空数组。
当你使用 `dependencies` 时，不会考虑上一个作业的状态。 当你使用 `dependencies` 时，并不考虑上一个流水线任务的状态。如果流水线任务失败或者是未触发的手动流水线任务，则不会发生错误。
如果作业失败或者是未触发的手动作业，则不会发生错误。
以下示例定义了两个带有工件的作业：`build:osx` 和 以下示例定义了两个带有 `artifacts`的流水线任务：`build:osx` 和 `build：linux`。当 `test:osx` 执行时，`build:osx` 中的 `artifacts` 在构建的上下文中下载和提取。同样的事情发生于 `test:linux` 和来自 `build:linux` 的 `artifacts`。
`构建：linux`。当 `test:osx` 执行时，`build:osx` 中的工件
在构建的上下文中下载和提取。同样的事情发生
用于 `test:linux` 和来自 `build:linux` 的工件。
作业 `deploy` 下载所有先前作业的工件，因为 流水线任务 `deploy` 下载所有先前流水线任务的 `artifacts`，因为 [stage](#stages) 优先级：
[stage](#stages) 优先级：
```yaml ```yaml
构建：OSX： build:osx:
阶段：构建 stage: build
脚本：make build:osx script: make build:osx
文物： artifacts:
路径： paths:
- 二进制文件/ - binaries/
构建：Linux：
阶段：构建
脚本：make build：linux
文物：
路径：
- 二进制文件/
测试：OSX：
阶段：测试
脚本：进行测试：osx
依赖：
- 构建：OSX
测试：Linux： build:linux:
阶段：测试 stage: build
脚本：进行测试：linux script: make build:linux
依赖： artifacts:
- 构建：linux paths:
- binaries/
部署： test:osx:
阶段：部署 stage: test
脚本：进行部署 script: make test:osx
`` dependencies:
- build:osx
##### 依赖作业失败时 test:linux:
stage: test
script: make test:linux
dependencies:
- build:linux
> 在 GitLab 10.3 中引入。 deploy:
stage: deploy
script: make deploy
```
如果设置为依赖项的作业工件是 ##### 当依赖流水线任务失败时
[过期](#artifactsexpire_in) 或
[删除](../pipelines/job_artifacts.md#delete-job-artifacts)，然后
依赖作业失败。
####`工件：排除` 如果设置为依赖项的流水线任务 `artifacts`是 [`过期的`](#artifactsexpire_in) 或 `已删除`，则
依赖流水线任务失败。
> - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/15122) 在 GitLab 13.1 #### `artifacts:exclude`
> - 需要 GitLab Runner 13.1
`exclude` 可以防止将文件添加到工件中 `exclude` 可以防止将文件添加到 `artifacts`中。
档案。
类似于 [`artifacts:paths`](#artifactspaths)，`exclude` 路径是相对的 类似于 [`artifacts:paths`](#artifactspaths)，`exclude` 路径是相对于项目目录的。你可以使用通配符 [glob](https://en.wikipedia.org/wiki/Glob_(programming)) 或 [`doublestar.PathMatch`](https://pkg.go.dev/github.com/bmatcuk/doublestar@v1.2.2?tab=doc#PathMatch) 模式。
到项目目录。您可以使用通配符
[glob](https://en.wikipedia.org/wiki/Glob_(programming)) 或
[`doublestar.PathMatch`](https://pkg.go.dev/github.com/bmatcuk/doublestar@v1.2.2?tab=doc#PathMatch) 模式。
例如，要将所有文件存储在 `binaries/` 中，而不是将 `*.o` 文件存储在 例如，要存储在 `binaries/` 中的所有文件，而不存储 `binaries/` 中的子目录 `*.o` 文件：
`binaries/` 的子目录：
```yaml ```yaml
文物： artifacts:
路径： paths:
- 二进制文件/ - binaries/
排除： exclude:
- 二进制文件/**/*.o - binaries/**/*.o
`` ```
与 [`artifacts:paths`](#artifactspaths) 不同，`exclude` 路径不是递归的。要排除目录的所有内容，您可以显式匹配它们而不是匹配目录本身。 与 [`artifacts:paths`](#artifactspaths) 不同，`exclude` 路径不是递归的。要排除目录的所有内容，你可以显式匹配它们而不是匹配目录本身。
例如，要将所有文件存储在 `binaries/` 中，但没有位于 `temp/` 子目录中： 例如，要存储 `binaries/` 中的所有文件，但不包括位于 `temp/` 子目录中的文件：
```yaml ```yaml
文物： artifacts:
路径： paths:
- 二进制文件/ - binaries/
排除： exclude:
- 二进制文件/临时文件/**/* - binaries/temp/**/*
`` ```
与 [`artifacts:untracked`](#artifactsuntracked) 匹配的文件可以使用
`artifacts:exclude` 也是。
####`artifacts:expire_in` [`artifacts:untracked`](#artifactsuntracked) 匹配的文件也可以使用`artifacts:exclude` 来排除。
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16267) 在 GitLab 13.0 中的禁用功能标志后面，无论到期时间如何，都会保留最新的作业工件。 #### `artifacts:expire_in`
> - [在 GitLab 13.4 中设置默认行为](https://gitlab.com/gitlab-org/gitlab/-/issues/229936)。
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/241026) 在 GitLab 13.8 中，可以在项目级别禁用保持最新的工作工件。
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276583) 在 GitLab 13.9 中，可以在实例范围内禁用保持最新的作业工件。
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321323) 在 GitLab 13.12 中，无论过期时间如何，都会保留最新的管道工件。
使用 `expire_in` 指定 [job artifacts](../pipelines/job_artifacts.md) 之前存储多长时间 使用 `expire_in` 指定流水线任务的 `artifacts` 在它们过期并被删除之前存储多长时间。`expire_in` 设置不会影响到：
它们过期并被删除。`expire_in` 设置不会影响：
- 来自最新工作的工件，除非保留最新的工作工件是： - 来自最新流水线任务的 `artifacts`，除非保留最新的流水线任务 `artifacts`是在项目级别禁用的。
- [在项目级别禁用](../pipelines/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs)。 - 流水线 `artifacts`。以下情况的到期日期将无法指定：
- [禁用实例范围](../../user/admin_area/settings/continuous_integration.md#keep-the-latest-artifacts-for-all-jobs-in-the-latest-successful-pipelines)。 - 来自最新流水线的流水线 `artifacts`将永远保留。
- [管道工件](../pipelines/pipeline_artifacts.md)。无法指定一个 - 其它一周后删除 `artifacts` 的流水线。
这些的到期日期：
- 来自最新管道的管道工件将永远保留。
- 一周后删除其他管道工件。
`expire_in` 的值是以秒为单位的经过时间，除非提供了单位。有效值 `expire_in` 的值是以秒为单位的时间范围，除非提供了单位。有效值包括：
包括：
- `'42'` - `'42'`
- `42 秒` - `42 seconds`
- `3 分 4 秒` - `3 mins 4 sec`
- `2 小时 20 分钟` - `2 hrs 20 min`
- `2h20min` - `2h20min`
- `6 月 1 天` - `6 mos 1 day`
- `47 岁 6 mos 和 4d` - `47 yrs 6 mos and 4d`
- `3 周零 2 天` - `3 weeks and 2 days`
-`从不` - `never`
要在上传后一周使工件过期： 要在上传后一周使 `artifacts`过期，你可以这样设置：
```yaml ```yaml
工作： job:
文物： artifacts:
expire_in: 1 周 expire_in: 1 week
`` ```
当工件上传并存储在 GitLab 上时，到期时间段开始。如果到期
时间未定义，默认为
[实例范围设置](../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration)
（默认 30 天）。
要覆盖到期日期并保护工件不被自动删除： 当 `artifacts`上传并存储之后，到期时间段开始启动计时。如果到期时间未定义，则默认为 30 天。
- 使用职位页面上的**保留**按钮。 要覆盖到期日期并保护 `artifacts`不被自动删除，你可以这样做：
- [在 GitLab 13.3 及更高版本中](https://gitlab.com/gitlab-org/gitlab/-/issues/22761)，设置值
`expire_in` 到 `never`。
过期后，工件默认每小时删除一次（使用 cron 作业），并且不会 - 使用流水线任务页面上的**保留**按钮。
可以访问了。 - 将 `expire_in` 的值设置为 `never`。
####`工件：expose_as` 过期后， `artifacts` 默认每小时删除一次（使用 cron 流水线任务），并且不再可以进行访问。
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/15018) 在 GitLab 12.5 中。 #### `artifacts:expose_as`
使用 `expose_as` 关键字公开 [job artifacts](../pipelines/job_artifacts.md) 使用 `expose_as` 关键字在[合并请求](/docs/user/project/merge-request) UI 中公开流水线任务的 `artifacts`。
在 [合并请求](../../user/project/merge_requests/index.md) UI 中。
例如，要匹配单个文件： 例如，要匹配单个文件：
```yaml ```yaml
测试： test:
脚本：[“回声‘测试’> file.txt”] script: ["echo 'test' > file.txt"]
文物： artifacts:
暴露_作为：'工件1' expose_as: 'artifact 1'
路径：['file.txt'] paths: ['file.txt']
`` ```
有了这个配置，GitLab 添加了一个链接 **artifact 1** 到相关的合并请求 在进行了如上的配置后，会在相关的合并请求中添加一个 **artifact 1** 的链接并指向 `file1.txt`。要访问链接，在合并请求概述中的流水线图下方选择 **查看暴露的 `artifacts`**即可。
指向`file1.txt`。要访问链接，请选择**查看暴露的工件**
在合并请求概述中的管道图下方。
匹配整个目录的示例： 匹配整个目录的示例：
```yaml ```yaml
测试： test:
脚本：["mkdir test && echo 'test' > test/file.txt"] script: ["mkdir test && echo 'test' > test/file.txt"]
文物： artifacts:
暴露_作为：'工件1' expose_as: 'artifact 1'
路径：['测试/'] paths: ['test/']
`` ```
请注意以下事项： 注意事项：
- 使用变量定义`artifacts:paths` 时，不会在合并请求 UI 中显示工件。 - 使用变量定义 `artifacts:paths` 时，不会在合并请求 UI 中显示 `artifacts`。
- 每个合并请求最多可以公开 10 个作业工件。 - 每个合并请求最多可以显示 10 个流水线任务的 `artifacts`。
- 不支持全局模式。 - 不支持全局模式。
- 如果指定了目录，则链接到作业 [工件浏览器](../pipelines/job_artifacts.md#download-job-artifacts) 如果超过 - 如果指定了目录，并且目录中不止一个文件的话，则链接到流水线任务 `artifacts` 浏览器。
目录中的一个文件。 - 对于带有`.html`、`.htm`、`.txt`、`.json`、`.xml` 和 `.log` 扩展名，且[Pages](/docs/pages) ：
- 对于带有`.html`、`.htm`、`.txt`、`.json`、`.xml`、 - 启用，则自动呈现 `artifacts`。
和 `.log` 扩展名，如果 [GitLab Pages](../../administration/pages/index.md) 是： - 未启用，文件显示在 `artifacts` 浏览器中。
- 启用，GitLab 自动呈现工件。
- 未启用，文件显示在工件浏览器中。
####`工件：名称` #### `artifacts:name`
使用 `name` 指令定义创建的工件的名称 使用 `name` 指令定义创建的 `artifacts`的名称
档案。您可以为每个存档指定唯一的名称。`artifacts:name` 档案。你可以为每个存档指定唯一的名称。`artifacts:name`
变量可以使用任何[预定义变量](../variables/README.md)。 变量可以使用任何[预定义变量](../variables/README.md)。
默认名称是`artifacts`，下载后会变成`artifacts.zip`。 默认名称是`artifacts`，下载后会变成`artifacts.zip`。
要使用当前作业的名称创建存档： 要使用当前流水线任务的名称创建存档：
```yaml ```yaml
工作： 工作：
...@@ -2790,11 +2546,11 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。 ...@@ -2790,11 +2546,11 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。
- 二进制文件/ - 二进制文件/
`` ``
如果您的分支名称包含正斜杠 如果你的分支名称包含正斜杠
（例如`feature/my-feature`）建议使用`$CI_COMMIT_REF_SLUG` （例如`feature/my-feature`）建议使用`$CI_COMMIT_REF_SLUG`
而不是`$CI_COMMIT_REF_NAME` 来正确命名工件。 而不是`$CI_COMMIT_REF_NAME` 来正确命名 `artifacts`。
使用当前作业和当前分支的名称创建存档或 使用当前流水线任务和当前分支的名称创建存档或
标记仅包含二进制文件目录： 标记仅包含二进制文件目录：
```yaml ```yaml
...@@ -2817,7 +2573,7 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。 ...@@ -2817,7 +2573,7 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。
--- ---
如果您使用 **Windows Batch** 运行您的 shell 脚本，则需要替换 如果你使用 **Windows Batch** 运行你的 shell 脚本，则需要替换
`$` 和 `%`： `$` 和 `%`：
```yaml ```yaml
...@@ -2828,7 +2584,7 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。 ...@@ -2828,7 +2584,7 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。
- 二进制文件/ - 二进制文件/
`` ``
如果您使用 **Windows PowerShell** 运行您的 shell 脚本，则需要替换 如果你使用 **Windows PowerShell** 运行你的 shell 脚本，则需要替换
`$` 和 `$env:`： `$` 和 `$env:`：
```yaml ```yaml
...@@ -2839,10 +2595,10 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。 ...@@ -2839,10 +2595,10 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。
- 二进制文件/ - 二进制文件/
`` ``
####`工件：路径` ####` `artifacts`：路径`
路径是相对于项目目录（`$CI_PROJECT_DIR`），不能直接 路径是相对于项目目录（`$CI_PROJECT_DIR`），不能直接
它外面的链接。您可以使用使用 [glob](https://en.wikipedia.org/wiki/Glob_(programming)) 的通配符 它外面的链接。你可以使用使用 [glob](https://en.wikipedia.org/wiki/Glob_(programming)) 的通配符
模式和： 模式和：
- 在 [GitLab Runner 13.0](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2620) 及更高版本中， - 在 [GitLab Runner 13.0](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2620) 及更高版本中，
...@@ -2850,7 +2606,7 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。 ...@@ -2850,7 +2606,7 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。
- 在 GitLab Runner 12.10 及更早版本中， - 在 GitLab Runner 12.10 及更早版本中，
[`filepath.Match`](https://pkg.go.dev/path/filepath#Match)。 [`filepath.Match`](https://pkg.go.dev/path/filepath#Match)。
要限制特定作业从哪些作业获取工件，请参阅 [dependencies](#dependencies)。 要限制特定流水线任务从哪些流水线任务获取 `artifacts`，请参阅 [dependencies](#dependencies)。
发送 `binaries` 和 `.config` 中的所有文件： 发送 `binaries` 和 `.config` 中的所有文件：
...@@ -2861,7 +2617,7 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。 ...@@ -2861,7 +2617,7 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。
- .config - .config
`` ``
要禁用工件传递，请使用空 [dependencies](#dependencies) 定义作业： 要禁用 `artifacts`传递，请使用空 [dependencies](#dependencies) 定义流水线任务：
```yaml ```yaml
工作： 工作：
...@@ -2870,13 +2626,13 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。 ...@@ -2870,13 +2626,13 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。
依赖项：[] 依赖项：[]
`` ``
您可能只想为标记的发布创建工件以避免填充 你可能只想为标记的发布创建 `artifacts`以避免填充
使用临时构建工件构建服务器存储。 使用临时构建 `artifacts`构建服务器存储。
仅为标签创建工件（`default-job` 不创建工件）： 仅为标签创建 `artifacts`（`default-job` 不创建 `artifacts`）：
```yaml ```yaml
默认作业： 默认流水线任务：
脚本： 脚本：
- mvn 测试 -U - mvn 测试 -U
除了： 除了：
...@@ -2892,7 +2648,7 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。 ...@@ -2892,7 +2648,7 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。
- 标签 - 标签
`` ``
您也可以对目录使用通配符。例如，如果您想获取以 `xyz` 结尾的目录中的所有文件： 你也可以对目录使用通配符。例如，如果你想获取以 `xyz` 结尾的目录中的所有文件：
```yaml ```yaml
工作： 工作：
...@@ -2901,46 +2657,46 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。 ...@@ -2901,46 +2657,46 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。
- 路径/*xyz/* - 路径/*xyz/*
`` ``
####`工件：公共` ####` `artifacts`：公共`
> - [介绍](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49775) 在 GitLab 13.8 > - [介绍](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49775) 在 GitLab 13.8
> - 它[部署在功能标志后面](../../user/feature_flags.md)，默认情况下禁用。 > - 它[部署在功能标志后面](../../user/feature_flags.md)，默认情况下禁用。
> - 它已在 GitLab.com 上启用。 > - 它已在 GitLab.com 上启用。
> - 推荐用于生产。 > - 推荐用于生产。
使用 `artifacts:public` 来确定作业工件是否应该 使用 `artifacts:public` 来确定流水线任务 `artifacts`是否应该
公开可用。 公开可用。
`artifacts:public` 的默认值为 `true`，这意味着 `artifacts:public` 的默认值为 `true`，这意味着
匿名和访客用户可以下载公共管道： 匿名和访客用户可以下载公共流水线：
```yaml ```yaml
文物： 文物：
公众：真实 公众：真实
`` ``
拒绝匿名用户和访客用户对公共工件的读取访问 拒绝匿名用户和访客用户对公共 `artifacts`的读取访问
管道，将 `artifacts:public` 设置为 `false`： 流水线，将 `artifacts:public` 设置为 `false`：
```yaml ```yaml
文物： 文物：
公众：假 公众：假
`` ``
####`工件：报告` ####` `artifacts`：报告`
> - [介绍](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20390) 在 GitLab 11.2 中。 > - [介绍](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20390) 在 GitLab 11.2 中。
> - 需要 GitLab Runner 11.2 及更高版本。 > - 需要 GitLab Runner 11.2 及更高版本。
使用 [`artifacts:reports`](#artifactsreports) 使用 [`artifacts:reports`](#artifactsreports)
从作业中收集测试报告、代码质量报告和安全报告。 从流水线任务中收集测试报告、代码质量报告和安全报告。
它还在 GitLab UI 中公开这些报告（合并请求、管道视图和安全仪表板）。 它还在 GitLab UI 中公开这些报告（合并请求、流水线视图和安全仪表板）。
无论作业结果如何（成功或失败），都会收集测试报告。 无论流水线任务结果如何（成功或失败），都会收集测试报告。
您可以使用 [`artifacts:expire_in`](#artifactsexpire_in) 来设置过期时间 你可以使用 [`artifacts:expire_in`](#artifactsexpire_in) 来设置过期时间
他们的文物的日期。 他们的文物的日期。
如果您还希望能够浏览报告输出文件，请包括 如果你还希望能够浏览报告输出文件，请包括
[`artifacts:paths`](#artifactspaths) 关键字。 [`artifacts:paths`](#artifactspaths) 关键字。
##### `artifacts:reports:api_fuzzing` **（终极）** ##### `artifacts:reports:api_fuzzing` **（终极）**
...@@ -2951,8 +2707,8 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。 ...@@ -2951,8 +2707,8 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。
`api_fuzzing` 报告收集了 [API Fuzzing bug](../../user/application_security/api_fuzzing/index.md) `api_fuzzing` 报告收集了 [API Fuzzing bug](../../user/application_security/api_fuzzing/index.md)
作为文物。 作为文物。
收集的 API Fuzzing 报告作为工件上传到 GitLab 并在合并中汇总 收集的 API Fuzzing 报告作为 `artifacts`上传到 GitLab 并在合并中汇总
请求和管道视图。它还用于为安全仪表板提供数据。 请求和流水线视图。它还用于为安全仪表板提供数据。
#####`artifacts:reports:cobertura` #####`artifacts:reports:cobertura`
...@@ -2960,7 +2716,7 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。 ...@@ -2960,7 +2716,7 @@ URI 编码的“%2F”。也禁止仅由点（`.`、`%2E`）组成的值。
> - 需要 [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 及更高版本。 > - 需要 [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 及更高版本。
`cobertura` 报告收集 [Cobertura 覆盖 XML 文件](../../user/project/merge_requests/test_coverage_visualization.md)。 `cobertura` 报告收集 [Cobertura 覆盖 XML 文件](../../user/project/merge_requests/test_coverage_visualization.md)。
收集的 Cobertura 覆盖率报告作为工件上传到 GitLab 收集的 Cobertura 覆盖率报告作为 `artifacts`上传到 GitLab
并显示在合并请求中。 并显示在合并请求中。
Cobertura 最初是为 Java 开发的，但也有很多 Cobertura 最初是为 Java 开发的，但也有很多
...@@ -2975,7 +2731,7 @@ Cobertura 最初是为 Java 开发的，但也有很多 ...@@ -2975,7 +2731,7 @@ Cobertura 最初是为 Java 开发的，但也有很多
`codequality` 报告收集[代码质量问题](../../user/project/merge_requests/code_quality.md) `codequality` 报告收集[代码质量问题](../../user/project/merge_requests/code_quality.md)
作为文物。 作为文物。
收集的代码质量报告作为工件上传到 GitLab，并在合并请求中汇总。 收集的代码质量报告作为 `artifacts`上传到 GitLab，并在合并请求中汇总。
##### `artifacts:reports:container_scanning` **（终极）** ##### `artifacts:reports:container_scanning` **（终极）**
...@@ -2985,8 +2741,8 @@ Cobertura 最初是为 Java 开发的，但也有很多 ...@@ -2985,8 +2741,8 @@ Cobertura 最初是为 Java 开发的，但也有很多
`container_scanning` 报告收集[容器扫描漏洞](../../user/application_security/container_scanning/index.md) `container_scanning` 报告收集[容器扫描漏洞](../../user/application_security/container_scanning/index.md)
作为文物。 作为文物。
收集到的容器扫描报告作为工件上传到 GitLab 收集到的容器扫描报告作为 `artifacts`上传到 GitLab
汇总在合并请求和管道视图中。它还用于提供数据以确保安全 汇总在合并请求和流水线视图中。它还用于提供数据以确保安全
仪表板。 仪表板。
##### `artifacts:reports:coverage_fuzzing` **（终极）** ##### `artifacts:reports:coverage_fuzzing` **（终极）**
...@@ -2997,8 +2753,8 @@ Cobertura 最初是为 Java 开发的，但也有很多 ...@@ -2997,8 +2753,8 @@ Cobertura 最初是为 Java 开发的，但也有很多
`coverage_fuzzing` 报告收集 [coverage fuzzing bug](../../user/application_security/coverage_fuzzing/index.md) `coverage_fuzzing` 报告收集 [coverage fuzzing bug](../../user/application_security/coverage_fuzzing/index.md)
作为文物。 作为文物。
收集到的覆盖模糊报告作为工件上传到 GitLab 并在合并中汇总 收集到的覆盖模糊报告作为 `artifacts`上传到 GitLab 并在合并中汇总
请求和管道视图。它还用于为安全仪表板提供数据。 请求和流水线视图。它还用于为安全仪表板提供数据。
##### `artifacts:reports:dast` **（终极）** ##### `artifacts:reports:dast` **（终极）**
...@@ -3008,7 +2764,7 @@ Cobertura 最初是为 Java 开发的，但也有很多 ...@@ -3008,7 +2764,7 @@ Cobertura 最初是为 Java 开发的，但也有很多
`dast` 报告收集 [DAST 漏洞](../../user/application_security/dast/index.md) `dast` 报告收集 [DAST 漏洞](../../user/application_security/dast/index.md)
作为文物。 作为文物。
收集的 DAST 报告作为工件上传到 GitLab，并在合并请求和管道视图中汇总。它还用于提供数据以确保安全 收集的 DAST 报告作为 `artifacts`上传到 GitLab，并在合并请求和流水线视图中汇总。它还用于提供数据以确保安全
仪表板。 仪表板。
##### `artifacts:reports:dependency_scanning` **（终极）** ##### `artifacts:reports:dependency_scanning` **（终极）**
...@@ -3019,7 +2775,7 @@ Cobertura 最初是为 Java 开发的，但也有很多 ...@@ -3019,7 +2775,7 @@ Cobertura 最初是为 Java 开发的，但也有很多
`dependency_scanning` 报告收集[依赖扫描漏洞](../../user/application_security/dependency_scanning/index.md) `dependency_scanning` 报告收集[依赖扫描漏洞](../../user/application_security/dependency_scanning/index.md)
作为文物。 作为文物。
收集到的依赖扫描报告作为工件上传到 GitLab，并在合并请求和管道视图中汇总。它还用于提供数据以确保安全 收集到的依赖扫描报告作为 `artifacts`上传到 GitLab，并在合并请求和流水线视图中汇总。它还用于提供数据以确保安全
仪表板。 仪表板。
##### `artifacts:reports:dotenv` ##### `artifacts:reports:dotenv`
...@@ -3027,10 +2783,10 @@ Cobertura 最初是为 Java 开发的，但也有很多 ...@@ -3027,10 +2783,10 @@ Cobertura 最初是为 Java 开发的，但也有很多
> - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/17066) 在 GitLab 12.9 中。 > - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/17066) 在 GitLab 12.9 中。
> - 需要 GitLab Runner 11.5 及更高版本。 > - 需要 GitLab Runner 11.5 及更高版本。
`dotenv` 报告收集一组环境变量作为工件。 `dotenv` 报告收集一组环境变量作为 `artifacts`。
收集的变量被注册为作业的运行时创建的变量， 收集的变量被注册为流水线任务的运行时创建的变量，
这对于[在作业完成后设置动态环境 URL](../environments/index.md#set-dynamic-environment-urls-after-a-job-finishes) 很有用。 这对于[在流水线任务完成后设置动态环境 URL](../environments/index.md#set-dynamic-environment-urls-after-a-job-finishes) 很有用。
[原始 dotenv 规则](https://github.com/motdotla/dotenv#rules) 有几个例外： [原始 dotenv 规则](https://github.com/motdotla/dotenv#rules) 有几个例外：
...@@ -3068,10 +2824,10 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3068,10 +2824,10 @@ JavaScript、Python、Ruby 等语言。
junit：rspec.xml junit：rspec.xml
`` ``
收集到的单元测试报告作为工件上传到 GitLab 并显示在合并请求中。 收集到的单元测试报告作为 `artifacts`上传到 GitLab 并显示在合并请求中。
如果您使用的 JUnit 工具导出到多个 XML 文件，请指定 如果你使用的 JUnit 工具导出到多个 XML 文件，请指定
单个作业中的多个测试报告路径 单个流水线任务中的多个测试报告路径
将它们连接成一个文件。使用文件名模式（`junit: rspec-*.xml`）， 将它们连接成一个文件。使用文件名模式（`junit: rspec-*.xml`），
文件名数组（`junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml]`），或 文件名数组（`junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml]`），或
其组合（`junit: [rspec.xml, test-results/TEST-*.xml]`）。 其组合（`junit: [rspec.xml, test-results/TEST-*.xml]`）。
...@@ -3082,14 +2838,14 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3082,14 +2838,14 @@ JavaScript、Python、Ruby 等语言。
> - 需要 GitLab Runner 11.5 及更高版本。 > - 需要 GitLab Runner 11.5 及更高版本。
警告： 警告：
此工件仍然有效，但**已弃用**以支持 此 `artifacts`仍然有效，但**已弃用**以支持
[artifacts:reports:license_scanning](#artifactsreportslicense_scanning) [artifacts:reports:license_scanning](#artifactsreportslicense_scanning)
在 GitLab 12.8 中引入。 在 GitLab 12.8 中引入。
`license_management` 报告收集 [Licenses](../../user/compliance/license_compliance/index.md) `license_management` 报告收集 [Licenses](../../user/compliance/license_compliance/index.md)
作为文物。 作为文物。
收集的许可证合规性报告作为工件上传到 GitLab，并在合并请求和管道视图中汇总。它还用于提供数据以确保安全 收集的许可证合规性报告作为 `artifacts`上传到 GitLab，并在合并请求和流水线视图中汇总。它还用于提供数据以确保安全
仪表板。 仪表板。
##### `artifacts:reports:license_scanning` **（终极）** ##### `artifacts:reports:license_scanning` **（终极）**
...@@ -3100,7 +2856,7 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3100,7 +2856,7 @@ JavaScript、Python、Ruby 等语言。
`license_scanning` 报告收集 [Licenses](../../user/compliance/license_compliance/index.md) `license_scanning` 报告收集 [Licenses](../../user/compliance/license_compliance/index.md)
作为文物。 作为文物。
许可证合规性报告作为工件上传到 GitLab 并自动显示在合并请求和管道视图中，并提供安全数据 许可证合规性报告作为 `artifacts`上传到 GitLab 并自动显示在合并请求和流水线视图中，并提供安全数据
仪表板。 仪表板。
##### `artifacts:reports:load_performance` **(PREMIUM)** ##### `artifacts:reports:load_performance` **(PREMIUM)**
...@@ -3111,7 +2867,7 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3111,7 +2867,7 @@ JavaScript、Python、Ruby 等语言。
`load_performance` 报告收集 [负载性能测试指标](../../user/project/merge_requests/load_performance_testing.md) `load_performance` 报告收集 [负载性能测试指标](../../user/project/merge_requests/load_performance_testing.md)
作为文物。 作为文物。
该报告作为工件上传到 GitLab，并且 该报告作为 `artifacts`上传到 GitLab，并且
自动显示在合并请求中。 自动显示在合并请求中。
##### `artifacts:reports:metrics` **(PREMIUM)** ##### `artifacts:reports:metrics` **(PREMIUM)**
...@@ -3121,7 +2877,7 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3121,7 +2877,7 @@ JavaScript、Python、Ruby 等语言。
`metrics` 报告收集 [Metrics](../metrics_reports.md) `metrics` 报告收集 [Metrics](../metrics_reports.md)
作为文物。 作为文物。
收集的指标报告作为工件上传到 GitLab 并显示在合并请求中。 收集的指标报告作为 `artifacts`上传到 GitLab 并显示在合并请求中。
##### `artifacts:reports:performance` **(PREMIUM)** ##### `artifacts:reports:performance` **(PREMIUM)**
...@@ -3131,16 +2887,16 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3131,16 +2887,16 @@ JavaScript、Python、Ruby 等语言。
`performance` 报告收集 [浏览器性能测试指标](../../user/project/merge_requests/browser_performance_testing.md) `performance` 报告收集 [浏览器性能测试指标](../../user/project/merge_requests/browser_performance_testing.md)
作为文物。 作为文物。
收集的浏览器性能报告作为工件上传到 GitLab 并显示在合并请求中。 收集的浏览器性能报告作为 `artifacts`上传到 GitLab 并显示在合并请求中。
##### `artifacts:reports:requirements` **（终极）** ##### `artifacts:reports:requirements` **（终极）**
> - [介绍](https://gitlab.com/groups/gitlab-org/-/epics/2859) 在 GitLab 13.1 中。 > - [介绍](https://gitlab.com/groups/gitlab-org/-/epics/2859) 在 GitLab 13.1 中。
> - 需要 GitLab Runner 11.5 及更高版本。 > - 需要 GitLab Runner 11.5 及更高版本。
`requirements` 报告收集 `requirements.json` 文件作为工件。 `requirements` 报告收集 `requirements.json` 文件作为 `artifacts`。
收集到的需求报告作为工件上传到 GitLab 收集到的需求报告作为 `artifacts`上传到 GitLab
现有的 [需求](../../user/project/requirements/index.md) 是 现有的 [需求](../../user/project/requirements/index.md) 是
标记为满意。 标记为满意。
...@@ -3153,8 +2909,8 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3153,8 +2909,8 @@ JavaScript、Python、Ruby 等语言。
`sast` 报告收集 [SAST 漏洞](../../user/application_security/sast/index.md) `sast` 报告收集 [SAST 漏洞](../../user/application_security/sast/index.md)
作为文物。 作为文物。
收集到的 SAST 报告作为工件上传到 GitLab 并进行汇总 收集到的 SAST 报告作为 `artifacts`上传到 GitLab 并进行汇总
在合并请求和管道视图中。它还用于提供数据以确保安全 在合并请求和流水线视图中。它还用于提供数据以确保安全
仪表板。 仪表板。
#####`artifacts:reports:secret_detection` #####`artifacts:reports:secret_detection`
...@@ -3167,8 +2923,8 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3167,8 +2923,8 @@ JavaScript、Python、Ruby 等语言。
`secret-detection` 报告收集 [检测到的机密](../../user/application_security/secret_detection/index.md) `secret-detection` 报告收集 [检测到的机密](../../user/application_security/secret_detection/index.md)
作为文物。 作为文物。
收集到的 Secret Detection 报告作为工件上传到 GitLab 并汇总 收集到的 Secret Detection 报告作为 `artifacts`上传到 GitLab 并汇总
在合并请求和管道视图中。它还用于提供数据以确保安全 在合并请求和流水线视图中。它还用于提供数据以确保安全
仪表板。 仪表板。
##### `artifacts:reports:terraform` ##### `artifacts:reports:terraform`
...@@ -3177,13 +2933,13 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3177,13 +2933,13 @@ JavaScript、Python、Ruby 等语言。
> - 需要 [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 及更高版本。 > - 需要 [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 及更高版本。
`terraform` 报告获取 Terraform `tfplan.json` 文件。[删除凭据所需的 JQ 处理](../../user/infrastructure/mr_integration.md#setup)。收集到的地形 `terraform` 报告获取 Terraform `tfplan.json` 文件。[删除凭据所需的 JQ 处理](../../user/infrastructure/mr_integration.md#setup)。收集到的地形
计划报告作为工件上传到 GitLab 并显示 计划报告作为 `artifacts`上传到 GitLab 并显示
在合并请求中。有关更多信息，请参阅 在合并请求中。有关更多信息，请参阅
[将 `terraform plan` 信息输出到合并请求中](../../user/infrastructure/mr_integration.md)。 [将 `terraform plan` 信息输出到合并请求中](../../user/infrastructure/mr_integration.md)。
#### `artifacts:untracked` #### `artifacts:untracked`
使用 `artifacts:untracked` 将所有 Git 未跟踪文件添加为工件（以及 使用 `artifacts:untracked` 将所有 Git 未跟踪文件添加为 `artifacts`（以及
使用 `artifacts:paths` 中定义的路径）。`artifacts:untracked` 忽略配置 使用 `artifacts:paths` 中定义的路径）。`artifacts:untracked` 忽略配置
在存储库的`.gitignore` 文件中。 在存储库的`.gitignore` 文件中。
...@@ -3212,20 +2968,20 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3212,20 +2968,20 @@ JavaScript、Python、Ruby 等语言。
- “*。文本文件” - “*。文本文件”
`` ``
####`工件：何时` ####` `artifacts`：何时`
使用 `artifacts:when` 在作业失败时上传工件或尽管 使用 `artifacts:when` 在流水线任务失败时上传 `artifacts`或尽管
失败。 失败。
`artifacts:when` 可以设置为以下值之一： `artifacts:when` 可以设置为以下值之一：
1. `on_success`（默认）：仅在作业成功时上传工件。 1. `on_success`（默认）：仅在流水线任务成功时上传 `artifacts`。
1. `on_failure`：仅在作业失败时上传工件。 1. `on_failure`：仅在流水线任务失败时上传 `artifacts`。
1. `always`：始终上传工件。很有用，例如，当 1. `always`：始终上传 `artifacts`。很有用，例如，当
[上传工件](../unit_test_reports.md#viewing-junit-screenshots-on-gitlab) 需要 [上传 `artifacts`](../unit_test_reports.md#viewing-junit-screenshots-on-gitlab) 需要
对失败的测试进行故障排除。 对失败的测试进行故障排除。
例如，仅在作业失败时上传工件： 例如，仅在流水线任务失败时上传 `artifacts`：
```yaml ```yaml
工作： 工作：
...@@ -3236,7 +2992,7 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3236,7 +2992,7 @@ JavaScript、Python、Ruby 等语言。
###`覆盖范围` ###`覆盖范围`
使用 `coverage` 配置如何从 使用 `coverage` 配置如何从
作业输出。 流水线任务输出。
正则表达式是此处预期的唯一有效值。所以，使用 正则表达式是此处预期的唯一有效值。所以，使用
围绕 `/` 是强制性的，以一致且明确地表示 围绕 `/` 是强制性的，以一致且明确地表示
...@@ -3251,26 +3007,26 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3251,26 +3007,26 @@ JavaScript、Python、Ruby 等语言。
覆盖率：'/代码覆盖率：\d+\.\d+/' 覆盖率：'/代码覆盖率：\d+\.\d+/'
`` ``
如果作业输出中至少有一行与正则表达式匹配，则覆盖率会显示在 UI 中。 如果流水线任务输出中至少有一行与正则表达式匹配，则覆盖率会显示在 UI 中。
如果作业输出中有多个匹配的行，则使用最后一行。 如果流水线任务输出中有多个匹配的行，则使用最后一行。
对于匹配的行，第一次出现 `\d+(\.\d+)?` 是代码覆盖率。 对于匹配的行，第一次出现 `\d+(\.\d+)?` 是代码覆盖率。
前导零被删除。 前导零被删除。
[子管道](../parent_child_pipelines.md) 的覆盖率输出未记录 [子流水线](../parent_child_pipelines.md) 的覆盖率输出未记录
或显示。检查[相关问题](https://gitlab.com/gitlab-org/gitlab/-/issues/280818) 或显示。检查[相关问题](https://gitlab.com/gitlab-org/gitlab/-/issues/280818)
更多细节。 更多细节。
###`重试` ###`重试`
> [介绍](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3515) 在 GitLab 11.5 中，您可以控制重试哪些故障。 > [介绍](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3515) 在 GitLab 11.5 中，你可以控制重试哪些故障。
使用 `retry` 配置一个作业的重试次数 使用 `retry` 配置一个流水线任务的重试次数
失败的情况。 失败的情况。
当一个作业失败时，该作业被重新处理， 当一个流水线任务失败时，该流水线任务被重新处理，
直到达到由 `retry` 关键字指定的限制。 直到达到由 `retry` 关键字指定的限制。
如果 `retry` 设置为 `2`，并且作业在第二次运行（第一次重试）中成功，则不会重试。 如果 `retry` 设置为 `2`，并且流水线任务在第二次运行（第一次重试）中成功，则不会重试。
`retry` 值必须是一个正整数，从 `0` 到 `2` `retry` 值必须是一个正整数，从 `0` 到 `2`
（最多重试两次，总共运行三次）。 （最多重试两次，总共运行三次）。
...@@ -3282,7 +3038,7 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3282,7 +3038,7 @@ JavaScript、Python、Ruby 等语言。
重试：2 重试：2
`` ``
默认情况下，在所有失败情况下都会重试作业。为了更好地控制 默认情况下，在所有失败情况下都会重试流水线任务。为了更好地控制
对于重试失败，“重试”可以是具有以下键的散列： 对于重试失败，“重试”可以是具有以下键的散列：
- `max`：最大重试次数。 - `max`：最大重试次数。
...@@ -3298,7 +3054,7 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3298,7 +3054,7 @@ JavaScript、Python、Ruby 等语言。
时间：runner_system_failure 时间：runner_system_failure
`` ``
如果除了流道系统故障之外还有其他故障，作业 如果除了流道系统故障之外还有其他故障，流水线任务
不重试。 不重试。
要重试多个失败案例，`when` 也可以是一个失败数组： 要重试多个失败案例，`when` 也可以是一个失败数组：
...@@ -3316,7 +3072,7 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3316,7 +3072,7 @@ JavaScript、Python、Ruby 等语言。
`when` 的可能值为： `when` 的可能值为：
<!-- <!--
如果您更改以下任何值，请确保更新 `RETRY_WHEN_IN_DOCUMENTATION` 如果你更改以下任何值，请确保更新 `RETRY_WHEN_IN_DOCUMENTATION`
`spec/lib/gitlab/ci/config/entry/retry_spec.rb` 中的数组。 `spec/lib/gitlab/ci/config/entry/retry_spec.rb` 中的数组。
那里的测试确保所有记录在案 那里的测试确保所有记录在案
值作为配置选项有效，因此应始终 值作为配置选项有效，因此应始终
...@@ -3327,24 +3083,24 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3327,24 +3083,24 @@ JavaScript、Python、Ruby 等语言。
- `unknown_failure`：失败原因未知时重试。 - `unknown_failure`：失败原因未知时重试。
- `script_failure`：脚本失败时重试。 - `script_failure`：脚本失败时重试。
- `api_failure`：API 失败时重试。 - `api_failure`：API 失败时重试。
- `stuck_or_timeout_failure`：当作业卡住或超时时重试。 - `stuck_or_timeout_failure`：当流水线任务卡住或超时时重试。
- `runner_system_failure`：如果存在运行器系统故障（例如，作业设置失败），则重试。 - `runner_system_failure`：如果存在运行器系统故障（例如，流水线任务设置失败），则重试。
- `missing_dependency_failure`：如果缺少依赖项，请重试。 - `missing_dependency_failure`：如果缺少依赖项，请重试。
- `runner_unsupported`：如果跑步者不受支持，则重试。 - `runner_unsupported`：如果跑步者不受支持，则重试。
- `stale_schedule`：如果无法执行延迟的作业，请重试。 - `stale_schedule`：如果无法执行延迟的流水线任务，请重试。
- `job_execution_timeout`：如果脚本超过为作业设置的最大执行时间，则重试。 - `job_execution_timeout`：如果脚本超过为流水线任务设置的最大执行时间，则重试。
- `archived_failure`：如果作业已存档且无法运行，请重试。 - `archived_failure`：如果流水线任务已存档且无法运行，请重试。
- `unmet_prerequisites`：如果作业未能完成先决任务，则重试。 - `unmet_prerequisites`：如果流水线任务未能完成先决任务，则重试。
- `scheduler_failure`：如果调度程序未能将作业分配给运行程序，则重试。 - `scheduler_failure`：如果调度程序未能将流水线任务分配给运行程序，则重试。
- `data_integrity_failure`：如果检测到结构完整性问题，请重试。 - `data_integrity_failure`：如果检测到结构完整性问题，请重试。
您可以使用变量指定[特定作业执行阶段的重试次数](../runners/README.md#job-stages-attempts)。 你可以使用变量指定[特定流水线任务执行阶段的重试次数](../runners/README.md#job-stages-attempts)。
###`超时` ###`超时`
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/14887) 在 GitLab 12.3 中。 > [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/14887) 在 GitLab 12.3 中。
使用 `timeout` 为特定作业配置超时。例如： 使用 `timeout` 为特定流水线任务配置超时。例如：
```yaml ```yaml
建造： 建造：
...@@ -3356,7 +3112,7 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3356,7 +3112,7 @@ JavaScript、Python、Ruby 等语言。
超时时间：3h 30m 超时时间：3h 30m
`` ``
作业级超时可以超过 流水线任务级超时可以超过
[项目级超时](../pipelines/settings.md#timeout) 但不能 [项目级超时](../pipelines/settings.md#timeout) 但不能
超过跑步者特定的超时时间。 超过跑步者特定的超时时间。
...@@ -3364,10 +3120,10 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3364,10 +3120,10 @@ JavaScript、Python、Ruby 等语言。
> [介绍](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21480) 在 GitLab 11.5 中。 > [介绍](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21480) 在 GitLab 11.5 中。
使用 `parallel` 配置要并行运行的作业实例的数量。 使用 `parallel` 配置要并行运行的流水线任务实例的数量。
该值可以是 2 到 50。 该值可以是 2 到 50。
`parallel` 关键字创建并行运行的同一作业的 N 个实例。 `parallel` 关键字创建并行运行的同一流水线任务的 N 个实例。
它们的命名顺序是从 `job_name 1/N` 到 `job_name N/N`： 它们的命名顺序是从 `job_name 1/N` 到 `job_name N/N`：
```yaml ```yaml
...@@ -3376,7 +3132,7 @@ JavaScript、Python、Ruby 等语言。 ...@@ -3376,7 +3132,7 @@ JavaScript、Python、Ruby 等语言。
平行：5 平行：5
`` ``
每个并行作业都有一个“CI_NODE_INDEX”和“CI_NODE_TOTAL” 每个并行流水线任务都有一个“CI_NODE_INDEX”和“CI_NODE_TOTAL”
[预定义 CI/CD 变量](../variables/README.md#predefined-cicd-variables) 设置。 [预定义 CI/CD 变量](../variables/README.md#predefined-cicd-variables) 设置。
不同的语言和测试套件有不同的方法来实现并行化。 不同的语言和测试套件有不同的方法来实现并行化。
...@@ -3402,21 +3158,21 @@ gem 'semaphore_test_boosters' ...@@ -3402,21 +3158,21 @@ gem 'semaphore_test_boosters'
警告： 警告：
Test Boosters 向作者报告使用统计数据。 Test Boosters 向作者报告使用统计数据。
然后，您可以导航到新管道构建的 **Jobs** 选项卡并查看您的 RSpec 然后，你可以导航到新流水线构建的 **Jobs** 选项卡并查看你的 RSpec
工作分为三个独立的工作。 流水线任务分为三个独立的流水线任务。
#### 并行`矩阵`作业 #### 并行`矩阵`流水线任务
> - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/15356) 在 GitLab 13.3 中。 > - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/15356) 在 GitLab 13.3 中。
使用 `matrix:` 在单个管道中并行运行作业多次， 使用 `matrix:` 在单个流水线中并行运行流水线任务多次，
但每个作业实例都有不同的变量值。 但每个流水线任务实例都有不同的变量值。
可以有 2 到 50 个工作岗位。 可以有 2 到 50 个流水线任务岗位。
作业只有在有多个跑步者或单个跑步者时才能并行运行 流水线任务只有在有多个跑步者或单个跑步者时才能并行运行
[配置为同时运行多个作业](#use-your-own-runners)。 [配置为同时运行多个流水线任务](#use-your-own-runners)。
每个作业都获得相同的 `CI_NODE_TOTAL` [CI/CD 变量](../variables/README.md#predefined-cicd-variables) 值和唯一的 `CI_NODE_INDEX` 值。 每个流水线任务都获得相同的 `CI_NODE_TOTAL` [CI/CD 变量](../variables/README.md#predefined-cicd-variables) 值和唯一的 `CI_NODE_INDEX` 值。
```yaml ```yaml
部署堆栈： 部署堆栈：
...@@ -3436,7 +3192,7 @@ Test Boosters 向作者报告使用统计数据。 ...@@ -3436,7 +3192,7 @@ Test Boosters 向作者报告使用统计数据。
堆栈：[数据，处理] 堆栈：[数据，处理]
`` ``
以下示例生成 10 个并行的 `deploystacks` 作业，每个作业具有不同的值 以下示例生成 10 个并行的 `deploystacks` 流水线任务，每个流水线任务具有不同的值
对于 `PROVIDER` 和 `STACK`： 对于 `PROVIDER` 和 `STACK`：
```明文 ```明文
...@@ -3452,13 +3208,13 @@ deploystacks: [ovh, 监控] ...@@ -3452,13 +3208,13 @@ deploystacks: [ovh, 监控]
部署堆栈：[vultr，处理] 部署堆栈：[vultr，处理]
`` ``
作业命名风格[在 GitLab 13.4 中改进](https://gitlab.com/gitlab-org/gitlab/-/issues/230452)。 流水线任务命名风格[在 GitLab 13.4 中改进](https://gitlab.com/gitlab-org/gitlab/-/issues/230452)。
#####一维`矩阵`作业 #####一维`矩阵`流水线任务
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/26362) 在 GitLab 13.5 中。 > [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/26362) 在 GitLab 13.5 中。
您还可以在单​​个作业中使用一维矩阵： 你还可以在单​​个流水线任务中使用一维矩阵：
```yaml ```yaml
部署堆栈： 部署堆栈：
...@@ -3470,12 +3226,12 @@ deploystacks: [ovh, 监控] ...@@ -3470,12 +3226,12 @@ deploystacks: [ovh, 监控]
- 提供商：[aws、ovh、gcp、vultr] - 提供商：[aws、ovh、gcp、vultr]
`` ``
##### 并行`matrix` 触发作业 ##### 并行`matrix` 触发流水线任务
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/270957) 在 GitLab 13.10 中。 > [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/270957) 在 GitLab 13.10 中。
使用 `matrix:` 在单个管道中多次并行运行 [trigger](#trigger) 作业， 使用 `matrix:` 在单个流水线中多次并行运行 [trigger](#trigger) 流水线任务，
但每个作业实例都有不同的变量值。 但每个流水线任务实例都有不同的变量值。
```yaml ```yaml
部署堆栈： 部署堆栈：
...@@ -3492,8 +3248,8 @@ deploystacks: [ovh, 监控] ...@@ -3492,8 +3248,8 @@ deploystacks: [ovh, 监控]
堆栈：[数据] 堆栈：[数据]
`` ``
此示例生成 6 个并行的 `deploystacks` 触发器作业，每个作业具有不同的值 此示例生成 6 个并行的 `deploystacks` 触发器流水线任务，每个流水线任务具有不同的值
对于 `PROVIDER` 和 `STACK`，它们使用这些变量创建了 6 个不同的子管道。 对于 `PROVIDER` 和 `STACK`，它们使用这些变量创建了 6 个不同的子流水线。
```明文 ```明文
deploystacks：[aws，监控] deploystacks：[aws，监控]
...@@ -3509,30 +3265,30 @@ deploystacks: [ovh, 监控] ...@@ -3509,30 +3265,30 @@ deploystacks: [ovh, 监控]
> - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/8997) 在 [GitLab Premium](https://about.gitlab.com/pricing/) 11.8。 > - [介绍](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。 > - [移动](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) 在 12.8 中免费使用 GitLab。
使用 `trigger` 定义下游管道触发器。当 GitLab 开始一个 `trigger` 作业时， 使用 `trigger` 定义下游流水线触发器。当 GitLab 开始一个 `trigger` 流水线任务时，
创建下游管道。 创建下游流水线。
带有`trigger` 的作业只能使用[有限的关键字集](../multi_project_pipelines.md#limitations)。 带有`trigger` 的流水线任务只能使用[有限的关键字集](../multi_project_pipelines.md#limitations)。
例如，你不能用 [`script`](#script), [`before_script`](#before_script), 例如，你不能用 [`script`](#script), [`before_script`](#before_script),
或 [`after_script`](#after_script)。 或 [`after_script`](#after_script)。
您可以使用此关键字创建两种不同类型的下游管道： 你可以使用此关键字创建两种不同类型的下游流水线：
- [多项目管道](../multi_project_pipelines.md#creating-multi-project-pipelines-from-gitlab-ciyml) - [多项目流水线](../multi_project_pipelines.md#creating-multi-project-pipelines-from-gitlab-ciyml)
- [子管道](../parent_child_pipelines.md) - [子流水线](../parent_child_pipelines.md)
[在 GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/) 及更高版本，您可以 [在 GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/) 及更高版本，你可以
查看哪个作业触发了下游管道。在[管道图](../pipelines/index.md#visualize-pipelines)中， 查看哪个流水线任务触发了下游流水线。在[流水线图](../pipelines/index.md#visualize-pipelines)中，
将鼠标悬停在下游管道作业上。 将鼠标悬停在下游流水线流水线任务上。
在 [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/201938) 及更高版本中，您 在 [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/201938) 及更高版本中，你
可以在与 `trigger` 相同的作业中使用 [`when:manual`](#whenmanual)。在 GitLab 13.4 和 可以在与 `trigger` 相同的流水线任务中使用 [`when:manual`](#whenmanual)。在 GitLab 13.4 和
早些时候，将它们一起使用会导致错误 `jobs:#{job-name} when should be on_success, on_failure or always`。 早些时候，将它们一起使用会导致错误 `jobs:#{job-name} when should be on_success, on_failure or always`。
您[无法使用 API 启动`手动`触发器作业](https://gitlab.com/gitlab-org/gitlab/-/issues/284086)。 你[无法使用 API 启动`手动`触发器流水线任务](https://gitlab.com/gitlab-org/gitlab/-/issues/284086)。
#### 多项目管道的基本`trigger` 语法 #### 多项目流水线的基本`trigger` 语法
您可以使用 `trigger` 关键字配置下游触发器 你可以使用 `trigger` 关键字配置下游触发器
下游项目的完整路径： 下游项目的完整路径：
```yaml ```yaml
...@@ -3545,10 +3301,10 @@ deploystacks: [ovh, 监控] ...@@ -3545,10 +3301,10 @@ deploystacks: [ovh, 监控]
触发器：我的/部署 触发器：我的/部署
`` ``
#### 多项目管道的复杂`trigger` 语法 #### 多项目流水线的复杂`trigger` 语法
你可以配置一个 GitLab 用来创建的分支名称 你可以配置一个 GitLab 用来创建的分支名称
具有以下功能的下游管道： 具有以下功能的下游流水线：
```yaml ```yaml
规格： 规格：
...@@ -3562,7 +3318,7 @@ deploystacks: [ovh, 监控] ...@@ -3562,7 +3318,7 @@ deploystacks: [ovh, 监控]
分支：稳定 分支：稳定
`` ``
要从触发的管道镜像状态： 要从触发的流水线镜像状态：
```yaml ```yaml
trigger_job: trigger_job:
...@@ -3571,21 +3327,21 @@ trigger_job: ...@@ -3571,21 +3327,21 @@ trigger_job:
策略：依赖 策略：依赖
`` ``
要从上游管道镜像状态： 要从上游流水线镜像状态：
```yaml ```yaml
上游桥： 上游桥：
阶段：测试 阶段：测试
需要： 需要：
管道：其他/项目 流水线：其他/项目
`` ``
#### 子管道的`trigger` 语法 #### 子流水线的`trigger` 语法
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/16094) 在 GitLab 12.7 中。 > [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/16094) 在 GitLab 12.7 中。
要创建 [子管道](../parent_child_pipelines.md)，请指定路径 要创建 [子流水线](../parent_child_pipelines.md)，请指定路径
包含子管道配置的 YAML 文件： 包含子流水线配置的 YAML 文件：
```yaml ```yaml
trigger_job: trigger_job:
...@@ -3593,8 +3349,8 @@ trigger_job: ...@@ -3593,8 +3349,8 @@ trigger_job:
包括：path/to/child-pipeline.yml 包括：path/to/child-pipeline.yml
`` ``
类似于[多项目管道](../multi_project_pipelines.md#mirroring-status-from-triggered-pipeline)， 类似于[多项目流水线](../multi_project_pipelines.md#mirroring-status-from-triggered-pipeline)，
可以从触发的管道中镜像状态： 可以从触发的流水线中镜像状态：
```yaml ```yaml
trigger_job: trigger_job:
...@@ -3604,11 +3360,11 @@ trigger_job: ...@@ -3604,11 +3360,11 @@ trigger_job:
策略：依赖 策略：依赖
`` ``
##### 使用生成的配置文件触发子管道 ##### 使用生成的配置文件触发子流水线
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/35632) 在 GitLab 12.9 中。 > [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/35632) 在 GitLab 12.9 中。
您还可以从 [动态生成的配置文件](../parent_child_pipelines.md#dynamic-child-pipelines) 触发子管道： 你还可以从 [动态生成的配置文件](../parent_child_pipelines.md#dynamic-child-pipelines) 触发子流水线：
```yaml ```yaml
生成配置： 生成配置：
...@@ -3618,45 +3374,45 @@ trigger_job: ...@@ -3618,45 +3374,45 @@ trigger_job:
路径： 路径：
- 生成的 config.yml - 生成的 config.yml
子管道： 子流水线：
阶段：测试 阶段：测试
扳机： 扳机：
包括： 包括：
- 工件：生成的 config.yml - `artifacts`：生成的 config.yml
工作：生成配置 工作：生成配置
`` ``
`generated-config.yml` 从工件中提取并用作配置 `generated-config.yml` 从 `artifacts`中提取并用作配置
用于触发子管道。 用于触发子流水线。
##### 使用来自另一个项目的文件触发子管道 ##### 使用来自另一个项目的文件触发子流水线
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/205157) 在 GitLab 13.5 中。 > [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/205157) 在 GitLab 13.5 中。
使用来自同一私有项目的文件触发子管道 使用来自同一私有项目的文件触发子流水线
GitLab 实例，使用 [`include:file`](#includefile)： GitLab 实例，使用 [`include:file`](#includefile)：
```yaml ```yaml
子管道： 子流水线：
扳机： 扳机：
包括： 包括：
- 项目：'我的组/我的管道库' - 项目：'我的组/我的流水线库'
参考：'主要' 参考：'主要'
文件：'/path/to/child-pipeline.yml' 文件：'/path/to/child-pipeline.yml'
`` ``
#### 使用 `trigger:strategy` 链接管道 #### 使用 `trigger:strategy` 链接流水线
默认情况下，`trigger` 作业以 `success` 状态完成 默认情况下，`trigger` 流水线任务以 `success` 状态完成
一旦创建了下游管道。 一旦创建了下游流水线。
要强制 `trigger` 作业等待下游（多项目或子）管道完成，请使用 要强制 `trigger` 流水线任务等待下游（多项目或子）流水线完成，请使用
`策略：依赖`。此设置使触发作业以“正在运行”状态等待，直到触发 `策略：依赖`。此设置使触发流水线任务以“正在运行”状态等待，直到触发
管道完成。此时，`trigger` 作业完成并显示与 流水线完成。此时，`trigger` 流水线任务完成并显示与
下游作业。 下游流水线任务。
此设置有助于保持管道执行的线性。在以下示例中，作业来自 此设置有助于保持流水线执行的线性。在以下示例中，流水线任务来自
后续阶段等待触发的管道成功完成之前 后续阶段等待触发的流水线成功完成之前
开始，这减少了并行化。 开始，这减少了并行化。
```yaml ```yaml
...@@ -3666,9 +3422,9 @@ trigger_job: ...@@ -3666,9 +3422,9 @@ trigger_job:
策略：依赖 策略：依赖
`` ``
#### 通过 API 调用触发管道 #### 通过 API 调用触发流水线
要强制重建特定分支、标记或提交，您可以使用 API 调用 要强制重建特定分支、标记或提交，你可以使用 API 调用
带有触发令牌。 带有触发令牌。
触发标记不同于 [`trigger`](#trigger) 关键字。 触发标记不同于 [`trigger`](#trigger) 关键字。
...@@ -3679,25 +3435,25 @@ trigger_job: ...@@ -3679,25 +3435,25 @@ trigger_job:
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/32022) 在 GitLab 12.3 中。 > [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/32022) 在 GitLab 12.3 中。
使用 `interruptible` 表示如果新的管道运行变得多余，则应取消正在运行的作业。 使用 `interruptible` 表示如果新的流水线运行变得多余，则应取消正在运行的流水线任务。
默认为`false`（不可中断）。尚未开始（待处理）的作业被认为是可中断的 默认为`false`（不可中断）。尚未开始（待处理）的流水线任务被认为是可中断的
并且可以安全取消。 并且可以安全取消。
此值仅在 [自动取消冗余管道功能](../pipelines/settings.md#auto-cancel-redundant-pipelines) 时使用 此值仅在 [自动取消冗余流水线功能](../pipelines/settings.md#auto-cancel-redundant-pipelines) 时使用
已启用。 已启用。
启用后，如果以下任一情况为真，则在同一分支上启动新管道时会立即取消管道： 启用后，如果以下任一情况为真，则在同一分支上启动新流水线时会立即取消流水线：
- 管道中的所有作业都设置为可中断的。 - 流水线中的所有流水线任务都设置为可中断的。
- 任何不间断的工作尚未开始。 - 任何不间断的工作尚未开始。
将作业设置为可以在启动后安全取消的可中断作业（例如，构建作业）。 将流水线任务设置为可以在启动后安全取消的可中断流水线任务（例如，构建流水线任务）。
在以下示例中，新管道运行会导致现有运行管道变为： 在以下示例中，新流水线运行会导致现有运行流水线变为：
- 取消，如果只有 `step-1` 正在运行或未决。 - 取消，如果只有 `step-1` 正在运行或未决。
- 不会取消，一旦 `step-2` 开始运行。 - 不会取消，一旦 `step-2` 开始运行。
不间断作业开始运行后，管道无法取消。 不间断流水线任务开始运行后，流水线无法取消。
```yaml ```yaml
阶段： 阶段：
...@@ -3727,16 +3483,16 @@ trigger_job: ...@@ -3727,16 +3483,16 @@ trigger_job:
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/15536​​) 在 GitLab 12.7 中。 > [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/15536​​) 在 GitLab 12.7 中。
有时在一个环境中同时运行多个作业或管道 有时在一个环境中同时运行多个流水线任务或流水线
可能会导致部署过程中出现错误。 可能会导致部署过程中出现错误。
为避免这些错误，请使用 `resource_group` 属性来确保 为避免这些错误，请使用 `resource_group` 属性来确保
跑步者不会同时运行某些作业。资源组的行为相似 跑步者不会同时运行某些流水线任务。资源组的行为相似
到其他编程语言中的信号量。 到其他编程语言中的信号量。
当在 `.gitlab-ci.yml` 文件中为作业定义了 `resource_group` 关键字时， 当在 `.codechina-ci.yml` 文件中为流水线任务定义了 `resource_group` 关键字时，
同一项目的不同管道中的作业执行是相互排斥的。 同一项目的不同流水线中的流水线任务执行是相互排斥的。
如果属于同一资源组的多个作业同时入队， 如果属于同一资源组的多个流水线任务同时入队，
跑步者只选择其中一项工作。其他工作等到 跑步者只选择其中一项工作。其他工作等到
`resource_group` 是免费的。 `resource_group` 是免费的。
...@@ -3748,11 +3504,11 @@ trigger_job: ...@@ -3748,11 +3504,11 @@ trigger_job:
资源组：生产 资源组：生产
`` ``
在这种情况下，两个独立管道中的两个“部署到生产”作业永远不能同时运行。因此， 在这种情况下，两个独立流水线中的两个“部署到生产”流水线任务永远不能同时运行。因此，
您可以确保并发部署永远不会发生在生产环境中。 你可以确保并发部署永远不会发生在生产环境中。
您可以为每个环境定义多个资源组。例如， 你可以为每个环境定义多个资源组。例如，
部署到物理设备时，您可能有多个物理设备。每台设备 部署到物理设备时，你可能有多个物理设备。每台设备
可以部署到，但在任何给定时间每个设备只能有一个部署。 可以部署到，但在任何给定时间每个设备只能有一个部署。
`resource_group` 值只能包含字母、数字、`-`、`_`、`/`、`$`、`{`、`}`、`.` 和空格。 `resource_group` 值只能包含字母、数字、`-`、`_`、`/`、`$`、`{`、`}`、`.` 和空格。
...@@ -3760,23 +3516,23 @@ trigger_job: ...@@ -3760,23 +3516,23 @@ trigger_job:
有关更多信息，请参阅 [部署安全](../environments/deployment_safety.md)。 有关更多信息，请参阅 [部署安全](../environments/deployment_safety.md)。
#### 具有跨项目/父子管道的管道级并发控制 #### 具有跨项目/父子流水线的流水线级并发控制
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/39057) 在 GitLab 13.9 中。 > [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/39057) 在 GitLab 13.9 中。
您可以为对并发敏感的下游管道定义`resource_group` 你可以为对并发敏感的下游流水线定义`resource_group`
处决。[`trigger` 关键字](#trigger) 可以触发下游管道。这 处决。[`trigger` 关键字](#trigger) 可以触发下游流水线。这
[`resource_group` 关键字](#resource_group) 可以与它​​共存。这有助于控制 [`resource_group` 关键字](#resource_group) 可以与它​​共存。这有助于控制
部署管道的并发性，同时运行非敏感作业。 部署流水线的并发性，同时运行非敏感流水线任务。
以下示例在一个项目中有两个管道配置。当管道开始运行时， 以下示例在一个项目中有两个流水线配置。当流水线开始运行时，
非敏感作业首先执行，不受其他并发执行的影响 非敏感流水线任务首先执行，不受其他并发执行的影响
管道。但是，GitLab 确保之前没有其他部署管道在运行 流水线。但是，GitLab 确保之前没有其他部署流水线在运行
触发部署（子）管道。如果其他部署管道正在运行，GitLab 等待 触发部署（子）流水线。如果其他部署流水线正在运行，GitLab 等待
直到这些管道完成，然后再运行另一个。 直到这些流水线完成，然后再运行另一个。
```yaml ```yaml
# .gitlab-ci.yml（父管道） # .codechina-ci.yml（父流水线）
建造： 建造：
阶段：构建 阶段：构建
...@@ -3789,13 +3545,13 @@ trigger_job: ...@@ -3789,13 +3545,13 @@ trigger_job:
部署： 部署：
阶段：部署 阶段：部署
扳机： 扳机：
包括：deploy.gitlab-ci.yml 包括：deploy.codechina-ci.yml
策略：依赖 策略：依赖
资源组：AWS 生产 资源组：AWS 生产
`` ``
```yaml ```yaml
# deploy.gitlab-ci.yml（子管道） # deploy.codechina-ci.yml（子流水线）
阶段： 阶段：
- 条款 - 条款
...@@ -3810,8 +3566,8 @@ trigger_job: ...@@ -3810,8 +3566,8 @@ trigger_job:
脚本：echo“正在部署...” 脚本：echo“正在部署...”
`` ``
您必须定义 [`strategy:depend`](#linking-pipelines-with-triggerstrategy) 你必须定义 [`strategy:depend`](#linking-pipelines-with-triggerstrategy)
使用`trigger` 关键字。这确保在下游管道之前不会释放锁 使用`trigger` 关键字。这确保在下游流水线之前不会释放锁
完成。 完成。
###`发布` ###`发布`
...@@ -3820,7 +3576,7 @@ trigger_job: ...@@ -3820,7 +3576,7 @@ trigger_job:
使用 `release` 创建一个 [release](../../user/project/releases/index.md)。 使用 `release` 创建一个 [release](../../user/project/releases/index.md)。
需要 [`release-cli`](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs) 需要 [`release-cli`](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs)
在您的 GitLab Runner Docker 或 shell 执行器中可用。 在你的 GitLab Runner Docker 或 shell 执行器中可用。
支持这些关键字： 支持这些关键字：
...@@ -3832,12 +3588,12 @@ trigger_job: ...@@ -3832,12 +3588,12 @@ trigger_job:
- [`released_at`](#releasereleased_at)（可选） - [`released_at`](#releasereleased_at)（可选）
- [`assets:links`](#releaseassetslinks)（可选） - [`assets:links`](#releaseassetslinks)（可选）
仅当作业处理没有错误时才会创建发布。如果 Rails API 仅当流水线任务处理没有错误时才会创建发布。如果 Rails API
在发布创建期间返回错误，`release` 作业失败。 在发布创建期间返回错误，`release` 流水线任务失败。
#### `release-cli` Docker 镜像 #### `release-cli` Docker 镜像
您必须指定用于 `release-cli` 的 Docker 镜像： 你必须指定用于 `release-cli` 的 Docker 镜像：
```yaml ```yaml
图片：registry.gitlab.com/gitlab-org/release-cli:latest 图片：registry.gitlab.com/gitlab-org/release-cli:latest
...@@ -3847,12 +3603,12 @@ trigger_job: ...@@ -3847,12 +3603,12 @@ trigger_job:
> [介绍](https://gitlab.com/gitlab-org/release-cli/-/issues/21) 在 GitLab 13.8 中。 > [介绍](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`。 对于 GitLab Runner shell 执行程序，你可以为你的 [支持的操作系统和架构] (https://release-cli-downloads.s3.amazonaws.com/latest/index.html) 手动下载并安装 `release-cli`。
安装后，您应该可以使用`release` 关键字。 安装后，你应该可以使用`release` 关键字。
**在 Unix/Linux 上安装** **在 Unix/Linux 上安装**
1. 下载适用于您系统的二进制文件，以下示例适用于 amd64 系统： 1. 下载适用于你系统的二进制文件，以下示例适用于 amd64 系统：
```壳 ```壳
curl --location --output /usr/local/bin/release-cli "https://release-cli-downloads.s3.amazonaws.com/latest/release-cli-linux-amd64" curl --location --output /usr/local/bin/release-cli "https://release-cli-downloads.s3.amazonaws.com/latest/release-cli-linux-amd64"
...@@ -3892,7 +3648,7 @@ trigger_job: ...@@ -3892,7 +3648,7 @@ trigger_job:
`` ``
1. 将目录添加到您的 `$env:PATH`： 1. 将目录添加到你的 `$env:PATH`：
```壳 ```壳
$env:PATH += ";C:\GitLab\Release-CLI\bin" $env:PATH += ";C:\GitLab\Release-CLI\bin"
...@@ -3908,12 +3664,12 @@ trigger_job: ...@@ -3908,12 +3664,12 @@ trigger_job:
#### 使用自定义 SSL CA 证书颁发机构 #### 使用自定义 SSL CA 证书颁发机构
您可以使用 `ADDITIONAL_CA_CERT_BUNDLE` CI/CD 变量来配置自定义 SSL CA 证书颁发机构， 你可以使用 `ADDITIONAL_CA_CERT_BUNDLE` CI/CD 变量来配置自定义 SSL CA 证书颁发机构，
当`release-cli`使用带有自定义证书的HTTPS通过API创建发布时，它用于验证对等点。 当`release-cli`使用带有自定义证书的HTTPS通过API创建发布时，它用于验证对等点。
`ADDITIONAL_CA_CERT_BUNDLE` 值应包含 `ADDITIONAL_CA_CERT_BUNDLE` 值应包含
[X.509 PEM 公钥证书的文本表示](https://tools.ietf.org/html/rfc7468#section-5.1) [X.509 PEM 公钥证书的文本表示](https://tools.ietf.org/html/rfc7468#section-5.1)
或包含证书颁发机构的`path/to/file`。 或包含证书颁发机构的`path/to/file`。
例如，要在 `.gitlab-ci.yml` 文件中配置此值，请使用以下命令： 例如，要在 `.codechina-ci.yml` 文件中配置此值，请使用以下命令：
```yaml ```yaml
释放： 释放：
...@@ -3938,8 +3694,8 @@ trigger_job: ...@@ -3938,8 +3694,8 @@ trigger_job:
####`脚本` ####`脚本`
除 [trigger](#trigger) 作业之外的所有作业都必须具有 `script` 关键字。一个`发布` 除 [trigger](#trigger) 流水线任务之外的所有流水线任务都必须具有 `script` 关键字。一个`发布`
作业可以使用脚本命令的输出，但如果出现以下情况，您可以使用占位符脚本 流水线任务可以使用脚本命令的输出，但如果出现以下情况，你可以使用占位符脚本
不需要脚本： 不需要脚本：
```yaml ```yaml
...@@ -3949,7 +3705,7 @@ trigger_job: ...@@ -3949,7 +3705,7 @@ trigger_job:
[问题](https://gitlab.com/gitlab-org/gitlab/-/issues/223856) 存在以在即将发布的 GitLab 版本中删除此要求。 [问题](https://gitlab.com/gitlab-org/gitlab/-/issues/223856) 存在以在即将发布的 GitLab 版本中删除此要求。
一个管道可以有多个“发布”作业，例如： 一个流水线可以有多个“发布”流水线任务，例如：
```yaml ```yaml
ios-发布： ios-发布：
...@@ -3969,10 +3725,10 @@ ios-发布： ...@@ -3969,10 +3725,10 @@ ios-发布：
####`release:tag_name` ####`release:tag_name`
您必须为发布指定一个 `tag_name`。该标签可以引用现有的 Git 标签或 你必须为发布指定一个 `tag_name`。该标签可以引用现有的 Git 标签或
您可以指定一个新标签。 你可以指定一个新标签。
当存储库中不存在指定的标签时，将从管道的关联 SHA 创建一个新标签。 当存储库中不存在指定的标签时，将从流水线的关联 SHA 创建一个新标签。
例如，从 Git 标签创建发布时： 例如，从 Git 标签创建发布时：
...@@ -3993,8 +3749,8 @@ ios-发布： ...@@ -3993,8 +3749,8 @@ ios-发布：
description: '发布说明' description: '发布说明'
`` ``
- 只有当作业的主脚本成功时才会创建发布。 - 只有当流水线任务的主脚本成功时才会创建发布。
- 如果发布已经存在，则不会更新并且带有`release` 关键字的作业失败。 - 如果发布已经存在，则不会更新并且带有`release` 关键字的流水线任务失败。
- `release` 部分在 `script` 标签之后和 `after_script` 之前执行。 - `release` 部分在 `script` 标签之后和 `after_script` 之前执行。
####`发布：名称` ####`发布：名称`
...@@ -4003,7 +3759,7 @@ ios-发布： ...@@ -4003,7 +3759,7 @@ ios-发布：
####`发布：描述` ####`发布：描述`
指定发布的详细描述。您还可以指定一个包含 指定发布的详细描述。你还可以指定一个包含
描述。 描述。
##### 从文件中读取描述 ##### 从文件中读取描述
...@@ -4062,7 +3818,7 @@ ios-发布： ...@@ -4062,7 +3818,7 @@ ios-发布：
#### `release` 的完整示例 #### `release` 的完整示例
如果你结合之前的 `release` 例子，你会得到两个选项，这取决于你如何生成 如果你结合之前的 `release` 例子，你会得到两个选项，这取决于你如何生成
标签。您不能同时使用这些选项，因此请选择一个： 标签。你不能同时使用这些选项，因此请选择一个：
- 在推送 Git 标签或添加 Git 标签时创建发布 - 在推送 Git 标签或添加 Git 标签时创建发布
通过转到 **Repository > Tags** 在 UI 中： 通过转到 **Repository > Tags** 在 UI 中：
...@@ -4072,13 +3828,13 @@ ios-发布： ...@@ -4072,13 +3828,13 @@ ios-发布：
阶段：发布 阶段：发布
图片：registry.gitlab.com/gitlab-org/release-cli:latest 图片：registry.gitlab.com/gitlab-org/release-cli:latest
规则： 规则：
- if: $CI_COMMIT_TAG # 手动创建标签时运行此作业 - if: $CI_COMMIT_TAG # 手动创建标签时运行此流水线任务
脚本： 脚本：
- echo '正在运行 release_job' - echo '正在运行 release_job'
释放： 释放：
name: '发布 $CI_COMMIT_TAG' name: '发布 $CI_COMMIT_TAG'
描述：'使用 release-cli $EXTRA_DESCRIPTION 创建' # $EXTRA_DESCRIPTION 必须被定义 描述：'使用 release-cli $EXTRA_DESCRIPTION 创建' # $EXTRA_DESCRIPTION 必须被定义
tag_name: '$CI_COMMIT_TAG' # 管道中的其他地方。 tag_name: '$CI_COMMIT_TAG' # 流水线中的其他地方。
参考：'$CI_COMMIT_TAG' 参考：'$CI_COMMIT_TAG'
里程碑： 里程碑：
- 'm1' - 'm1'
...@@ -4108,14 +3864,14 @@ ios-发布： ...@@ -4108,14 +3864,14 @@ ios-发布：
stage: prepare # 这个阶段必须在发布阶段之前运行 stage: prepare # 这个阶段必须在发布阶段之前运行
规则： 规则：
- 如果：$CI_COMMIT_TAG - 如果：$CI_COMMIT_TAG
when: never # 手动创建标签时不要运行此作业 when: never # 手动创建标签时不要运行此流水线任务
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 当提交被推送或合并到默认分支时运行这个作业 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 当提交被推送或合并到默认分支时运行这个流水线任务
脚本： 脚本：
- echo "EXTRA_DESCRIPTION=some message" >> variables.env # 生成 EXTRA_DESCRIPTION 和 TAG 环境变量 - echo "EXTRA_DESCRIPTION=some message" >> variables.env # 生成 EXTRA_DESCRIPTION 和 TAG 环境变量
- echo "TAG=v$(cat VERSION)" >> variables.env # 并附加到 variables.env 文件 - echo "TAG=v$(cat VERSION)" >> variables.env # 并附加到 variables.env 文件
文物： 文物：
报告： 报告：
dotenv: variables.env # 使用 artifacts:reports:dotenv 将变量暴露给其他作业 dotenv: variables.env # 使用 artifacts:reports:dotenv 将变量暴露给其他流水线任务
发布工作： 发布工作：
阶段：发布 阶段：发布
...@@ -4125,15 +3881,15 @@ ios-发布： ...@@ -4125,15 +3881,15 @@ ios-发布：
文物：真实 文物：真实
规则： 规则：
- 如果：$CI_COMMIT_TAG - 如果：$CI_COMMIT_TAG
when: never # 手动创建标签时不要运行此作业 when: never # 手动创建标签时不要运行此流水线任务
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 当提交被推送或合并到默认分支时运行这个作业 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 当提交被推送或合并到默认分支时运行这个流水线任务
脚本： 脚本：
- echo '为 $TAG 运行 release_job' - echo '为 $TAG 运行 release_job'
释放： 释放：
name: '发布 $TAG' name: '发布 $TAG'
描述：“使用 release-cli $EXTRA_DESCRIPTION 创建”# $EXTRA_DESCRIPTION 和 $TAG 描述：“使用 release-cli $EXTRA_DESCRIPTION 创建”# $EXTRA_DESCRIPTION 和 $TAG
tag_name: '$TAG' # 变量必须在别处定义 tag_name: '$TAG' # 变量必须在别处定义
ref: '$CI_COMMIT_SHA' # 在管道中。例如，在 ref: '$CI_COMMIT_SHA' # 在流水线中。例如，在
里程碑：# prepare_job 里程碑：# prepare_job
- 'm1' - 'm1'
- 'm2' - 'm2'
...@@ -4151,7 +3907,7 @@ ios-发布： ...@@ -4151,7 +3907,7 @@ ios-发布：
#### 将资产发布为通用包 #### 将资产发布为通用包
您可以使用 [通用包](../../user/packages/generic_packages/) 来托管您的发布资产。 你可以使用 [通用包](../../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 assets as Generic packages](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs/examples/release-assets-as-generic-package /)
项目。 项目。
...@@ -4161,7 +3917,7 @@ ios-发布： ...@@ -4161,7 +3917,7 @@ ios-发布：
到 Docker 容器，其中包含 [release-cli](https://gitlab.com/gitlab-org/release-cli)。 到 Docker 容器，其中包含 [release-cli](https://gitlab.com/gitlab-org/release-cli)。
你也可以直接从 `script` 条目调用 `release-cli`。 你也可以直接从 `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\"} 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\"}
...@@ -4171,8 +3927,8 @@ release-cli create --name "Release $CI_COMMIT_SHA" --description "使用 release ...@@ -4171,8 +3927,8 @@ release-cli create --name "Release $CI_COMMIT_SHA" --description "使用 release
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33014) 在 GitLab 13.4 中。 > [介绍](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33014) 在 GitLab 13.4 中。
使用 `secrets` 指定作业需要的 [CI/CD Secrets](../secrets/index.md)。它应该是一个哈希， 使用 `secrets` 指定流水线任务需要的 [CI/CD Secrets](../secrets/index.md)。它应该是一个哈希，
键应该是可供作业使用的变量的名称。 键应该是可供流水线任务使用的变量的名称。
每个秘密的值都保存在一个临时文件中。这个文件的路径存储在这些 每个秘密的值都保存在一个临时文件中。这个文件的路径存储在这些
变量。 变量。
...@@ -4194,7 +3950,7 @@ release-cli create --name "Release $CI_COMMIT_SHA" --description "使用 release ...@@ -4194,7 +3950,7 @@ release-cli create --name "Release $CI_COMMIT_SHA" --description "使用 release
vault: production/db/password # 转换为秘密 `kv-v2/data/production/db`，字段 `password` vault: production/db/password # 转换为秘密 `kv-v2/data/production/db`，字段 `password`
`` ``
您可以通过添加以 `@` 开头的后缀来指定自定义机密引擎路径： 你可以通过添加以 `@` 开头的后缀来指定自定义机密引擎路径：
```yaml ```yaml
工作： 工作：
...@@ -4203,7 +3959,7 @@ release-cli create --name "Release $CI_COMMIT_SHA" --description "使用 release ...@@ -4203,7 +3959,7 @@ release-cli create --name "Release $CI_COMMIT_SHA" --description "使用 release
vault: production/db/password@ops # 转换为秘密 `ops/data/production/db`，字段 `password` vault: production/db/password@ops # 转换为秘密 `ops/data/production/db`，字段 `password`
`` ``
在语法的详细形式中，您可以明确指定所有详细信息： 在语法的详细形式中，你可以明确指定所有详细信息：
```yaml ```yaml
工作： 工作：
...@@ -4331,20 +4087,20 @@ release-cli create --name "Release $CI_COMMIT_SHA" --description "使用 release ...@@ -4331,20 +4087,20 @@ release-cli create --name "Release $CI_COMMIT_SHA" --description "使用 release
> 在 GitLab Runner v0.5.0 中引入。 > 在 GitLab Runner v0.5.0 中引入。
[CI/CD 变量](../variables/README.传递给作业的可配置值。 [CI/CD 变量](../variables/README.传递给流水线任务的可配置值。
它们可以在全局和每个作业中设置。 它们可以在全局和每个流水线任务中设置。
有两种类型的变量。 有两种类型的变量。
- [自定义变量](../variables/READMstom-cicd-variables): - [自定义变量](../variables/READMstom-cicd-variables):
您可以在 GitLab UI 中的 `.gitlal` 文件中定义它们的值， 你可以在 GitLab UI 中的 `.gitlal` 文件中定义它们的值，
或通过使用 API。您还可以在 GitL中输入变量 或通过使用 API。你还可以在 GitL中输入变量
[手动运行管道](../pipelines/indun-a-pipeline-manually)。 [手动运行流水线](../pipelines/indun-a-pipeline-manually)。
- [预定义变量](../variables/predeariables.md): - [预定义变量](../variables/predeariables.md):
这些值由跑步者自己设置。 这些值由跑步者自己设置。
一个例子是`CI_COMMIT_REF_NAME项目构建的分支或标签。 一个例子是`CI_COMMIT_REF_NAME项目构建的分支或标签。
定义变量后，您可以在所有执行的中使用它。 定义变量后，你可以在所有执行的中使用它。
变量用于非敏感项目配置，例如： 变量用于非敏感项目配置，例如：
...@@ -4352,7 +4108,7 @@ release-cli create --name "Release $CI_COMMIT_SHA" --description "使用 release ...@@ -4352,7 +4108,7 @@ release-cli create --name "Release $CI_COMMIT_SHA" --description "使用 release
变量： 变量：
DEPLOY_SITE: "https://example.c DEPLOY_SITE: "https://example.c
部署_作业： 部署_流水线任务：
阶段：部署 阶段：部署
脚本： 脚本：
- 部署脚本 --url $DEPLOY_SITE "/" - 部署脚本 --url $DEPLOY_SITE "/"
...@@ -4371,20 +4127,20 @@ deploy_review_job: ...@@ -4371,20 +4127,20 @@ deploy_review_job:
这意味着它适用于所有工作。如果定义变量，则它可用 这意味着它适用于所有工作。如果定义变量，则它可用
只到那个工作。 只到那个工作。
如果为特定作业全局定义了同名变 如果为特定流水线任务全局定义了同名变
[特定于作业的变量覆盖全局变量](..les/README.md#cicd-variable-precedence)。 [特定于流水线任务的变量覆盖全局变量](..les/README.md#cicd-variable-precedence)。
所有 YAML 定义的变量也设置为任何 所有 YAML 定义的变量也设置为任何
[Docker 服务容器](../services/ind [Docker 服务容器](../services/ind
您可以使用 [YAML 变量锚点](#yaml-or-variables)。 你可以使用 [YAML 变量锚点](#yaml-or-variables)。
### 在手动管道中预填充变量 ### 在手动流水线中预填充变量
> [引入](https://gitlab.com/gitlalab/-/issues/30101) GitLab 13.7。 > [引入](https://gitlab.com/gitlalab/-/issues/30101) GitLab 13.7。
使用 `value` 和 `description` 预先填充的管道级（全局）变量](../pipelines/index.md#prefill-variables-in-manuapipe 使用 `value` 和 `description` 预先填充的流水线级（全局）变量](../pipelines/index.md#prefill-variables-in-manuapipe
当[手动运行管道](../pipelines/ind-a-pipeline-manually)： 当[手动运行流水线](../pipelines/ind-a-pipeline-manually)：
```yaml ```yaml
变量： 变量：
...@@ -4393,11 +4149,11 @@ deploy_review_job: ...@@ -4393,11 +4149,11 @@ deploy_review_job:
描述：“部署目标。如果需要，为‘canary’或‘production’。” 描述：“部署目标。如果需要，为‘canary’或‘production’。”
`` ``
当您手动运行管道时，您无法将作预填充。 当你手动运行流水线时，你无法将作预填充。
### 使用变量配置跑步者行为 ### 使用变量配置跑步者行为
您可以使用 [CI/CD variables](../vREADME.md) 来配置运行程序如何处理 Git 请求： 你可以使用 [CI/CD variables](../vREADME.md) 来配置运行程序如何处理 Git 请求：
- [`GIT_STRATEGY`](../runners/REAt-strategy) - [`GIT_STRATEGY`](../runners/REAt-strategy)
- [`GIT_SUBMODULE_STRATEGY`](../rADME.md#git-submodule-strategy) - [`GIT_SUBMODULE_STRATEGY`](../rADME.md#git-submodule-strategy)
...@@ -4406,25 +4162,25 @@ deploy_review_job: ...@@ -4406,25 +4162,25 @@ deploy_review_job:
- [`GIT_FETCH_EXTRA_FLAGS`](../ruDME.md#git-fetch-extra-flags) - [`GIT_FETCH_EXTRA_FLAGS`](../ruDME.md#git-fetch-extra-flags)
- [`GIT_DEPTH`](../runners/READMEow-cloning)（浅克隆） - [`GIT_DEPTH`](../runners/READMEow-cloning)（浅克隆）
- [`GIT_CLONE_PATH`](../runners/Rcustom-build-directories)（自定义构建目录） - [`GIT_CLONE_PATH`](../runners/Rcustom-build-directories)（自定义构建目录）
- [`TRANSFER_METER_FREQUENCY`](..README.md#artifact-and-cache-settings)（工件/缓存表更新频率） - [`TRANSFER_METER_FREQUENCY`](..README.md#artifact-and-cache-settings)（ `artifacts`/缓存表更新频率）
- [`ARTIFACT_COMPRESSION_LEVEL`](s/README.md#artifact-and-cache-settings)（工件存档器压缩级别） - [`ARTIFACT_COMPRESSION_LEVEL`](s/README.md#artifact-and-cache-settings)（ `artifacts`存档器压缩级别）
- [`CACHE_COMPRESSION_LEVEL`](../EADME.md#artifact-and-cache-settings)（缓存归档压缩级别） - [`CACHE_COMPRESSION_LEVEL`](../EADME.md#artifact-and-cache-settings)（缓存归档压缩级别）
您还可以使用变量来配置跑步者的次数 你还可以使用变量来配置跑步者的次数
[尝试作业执行的某些阶段](../runne.md#job-stages-attempts)。 [尝试流水线任务执行的某些阶段](../runne.md#job-stages-attempts)。
## YAML 特定的功能 ## YAML 特定的功能
在你的 `.gitlab-ci.yml` 文件中AML 特定的特性，比如锚点（`&`）、别名（`*`）、 在你的 `.codechina-ci.yml` 文件中AML 特定的特性，比如锚点（`&`）、别名（`*`）、
和地图合并（`<<`）。使用这些功 和地图合并（`<<`）。使用这些功
`.gitlab-ci.yml` 文件中的代码。 `.codechina-ci.yml` 文件中的代码。
阅读有关各种 [YAML 功能](https://minutes.com/docs/yaml/) 的更多信息。 阅读有关各种 [YAML 功能](https://minutes.com/docs/yaml/) 的更多信息。
在大多数情况下，[`extends` 关键字s) 对用户更友好，您应该 在大多数情况下，[`extends` 关键字s) 对用户更友好，你应该
尽可能使用它。 尽可能使用它。
您可以使用 YAML 锚点来合并 YAML 。 你可以使用 YAML 锚点来合并 YAML 。
### 锚 ### 锚
...@@ -4432,7 +4188,7 @@ YAML 有一个叫做“锚点”的功能，你制 ...@@ -4432,7 +4188,7 @@ YAML 有一个叫做“锚点”的功能，你制
整个文档的内容。 整个文档的内容。
使用锚点复制或继承属性。将锚点与作](#hide-jobs) 结合使用 使用锚点复制或继承属性。将锚点与作](#hide-jobs) 结合使用
为您的工作提供模板。当有重复的键 为你的工作提供模板。当有重复的键
基于键执行反向深度合并。 基于键执行反向深度合并。
使用 [`include`](#include) 时，文件使用 YAML 锚点 使用 [`include`](#include) 时，文件使用 YAML 锚点
...@@ -4490,7 +4246,7 @@ YAML 有一个叫做“锚点”的功能，你制 ...@@ -4490,7 +4246,7 @@ YAML 有一个叫做“锚点”的功能，你制
- 测试2项目 - 测试2项目
`` ``
您可以使用锚点来定义两组服务。例如，`test:postgres` 你可以使用锚点来定义两组服务。例如，`test:postgres`
和 `test:mysql` 共享 `.job_template` 中定义的 `script`，但使用不同的 和 `test:mysql` 共享 `.job_template` 中定义的 `script`，但使用不同的
`services`，在 `.postgres_services` 和 `.mysql_services` 中定义： `services`，在 `.postgres_services` 和 `.mysql_services` 中定义：
...@@ -4560,15 +4316,15 @@ YAML 有一个叫做“锚点”的功能，你制 ...@@ -4560,15 +4316,15 @@ YAML 有一个叫做“锚点”的功能，你制
- 开发 - 开发
`` ``
您可以看到隐藏的作业可以方便地用作模板，并且 你可以看到隐藏的流水线任务可以方便地用作模板，并且
`tags: [postgres]` 覆盖 `tags: [dev]`。 `tags: [postgres]` 覆盖 `tags: [dev]`。
#### 脚本的 YAML 锚点 #### 脚本的 YAML 锚点
> [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/23005) 在 GitLab 12.5 中。 > [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/23005) 在 GitLab 12.5 中。
您可以将 [YAML 锚点](#anchors) 与 [script](#script)、[`before_script`](#before_script)、 你可以将 [YAML 锚点](#anchors) 与 [script](#script)、[`before_script`](#before_script)、
和 [`after_script`](#after_script) 在多个作业中使用预定义的命令： 和 [`after_script`](#after_script) 在多个流水线任务中使用预定义的命令：
```yaml ```yaml
.some-script-before: &some-script-before .some-script-before: &some-script-before
...@@ -4601,7 +4357,7 @@ YAML 有一个叫做“锚点”的功能，你制 ...@@ -4601,7 +4357,7 @@ YAML 有一个叫做“锚点”的功能，你制
#### 变量的 YAML 锚点 #### 变量的 YAML 锚点
使用 [YAML 锚点](#anchors) 和 `variables` 重复赋值 使用 [YAML 锚点](#anchors) 和 `variables` 重复赋值
跨多个作业的变量。您还可以在作业时使用 YAML 锚点 跨多个流水线任务的变量。你还可以在流水线任务时使用 YAML 锚点
需要一个特定的 `variables` 块，否则会覆盖全局变量。 需要一个特定的 `variables` 块，否则会覆盖全局变量。
以下示例显示如何在不影响的情况下覆盖 `GIT_STRATEGY` 变量 以下示例显示如何在不影响的情况下覆盖 `GIT_STRATEGY` 变量
...@@ -4613,7 +4369,7 @@ YAML 有一个叫做“锚点”的功能，你制 ...@@ -4613,7 +4369,7 @@ YAML 有一个叫做“锚点”的功能，你制
SAMPLE_VARIABLE：sample_variable_value SAMPLE_VARIABLE：sample_variable_value
ANOTHER_SAMPLE_VARIABLE：another_sample_variable_value ANOTHER_SAMPLE_VARIABLE：another_sample_variable_value
# 一个必须设置 GIT_STRATEGY 变量但依赖于全局变量的作业 # 一个必须设置 GIT_STRATEGY 变量但依赖于全局变量的流水线任务
job_no_git_strategy: job_no_git_strategy:
阶段：清理 阶段：清理
变量： 变量：
...@@ -4624,8 +4380,8 @@ job_no_git_strategy: ...@@ -4624,8 +4380,8 @@ job_no_git_strategy:
### 隐藏工作 ### 隐藏工作
如果你想暂时禁用一个作业，而不是注释掉所有的 如果你想暂时禁用一个流水线任务，而不是注释掉所有的
定义作业的行： 定义流水线任务的行：
```yaml ```yaml
# hidden_​​job: # hidden_​​job:
...@@ -4642,21 +4398,21 @@ job_no_git_strategy: ...@@ -4642,21 +4398,21 @@ job_no_git_strategy:
- 运行测试 - 运行测试
`` ``
使用此功能忽略作业，或使用 使用此功能忽略流水线任务，或使用
[YAML-specific features](#yaml-specific-features) 并转换隐藏作业 [YAML-specific features](#yaml-specific-features) 并转换隐藏流水线任务
成模板。 成模板。
### `!reference` 标签 ### `!reference` 标签
> - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/266173) 在 GitLab 13.9 中。 > - [介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/266173) 在 GitLab 13.9 中。
使用 `!reference` 自定义 YAML 标签从其他作业中选择关键字配置 使用 `!reference` 自定义 YAML 标签从其他流水线任务中选择关键字配置
部分并在当前部分中重用它。与 [YAML 锚点](#anchors) 不同，您可以 部分并在当前部分中重用它。与 [YAML 锚点](#anchors) 不同，你可以
使用 `!reference` 标签重用 [included](#include) 配置中的配置 使用 `!reference` 标签重用 [included](#include) 配置中的配置
文件也是如此。 文件也是如此。
在以下示例中，来自两个不同位置的 `script` 和一个 `after_script` 是 在以下示例中，来自两个不同位置的 `script` 和一个 `after_script` 是
在 `test` 作业中重用： 在 `test` 流水线任务中重用：
- `setup.yml`： - `setup.yml`：
...@@ -4666,7 +4422,7 @@ job_no_git_strategy: ...@@ -4666,7 +4422,7 @@ job_no_git_strategy:
- echo 创建环境 - echo 创建环境
`` ``
-`.gitlab-ci.yml`： -`.codechina-ci.yml`：
```yaml ```yaml
包括： 包括：
...@@ -4705,26 +4461,26 @@ job_no_git_strategy: ...@@ -4705,26 +4461,26 @@ job_no_git_strategy:
- 打印环境 - 打印环境
`` ``
您不能重复使用已经包含 `!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)。 或者，如果你使用 Git 2.10 或更高版本，请使用 `ci.skip` [Git push option](../../user/project/push_options.md#push-options-for-gitlab-cicd)。
`ci.skip` 推送选项不会跳过合并请求 `ci.skip` 推送选项不会跳过合并请求
管道。 流水线。
## 处理 Git 推送 ## 处理 Git 推送
GitLab 在以下情况下最多创建四个分支和标记管道 GitLab 在以下情况下最多创建四个分支和标记流水线
在单个 `git push` 调用中推送多个更改。 在单个 `git push` 调用中推送多个更改。
此限制不会影响任何更新的合并请求管道。 此限制不会影响任何更新的合并请求流水线。
所有更新的合并请求都在使用时创建了一个管道 所有更新的合并请求都在使用时创建了一个流水线
[合并请求的管道](../merge_request_pipelines/index.md)。 [合并请求的流水线](../merge_request_pipelines/index.md)。
## 弃用的关键字 ## 弃用的关键字
...@@ -4736,7 +4492,7 @@ GitLab 在以下情况下最多创建四个分支和标记管道 ...@@ -4736,7 +4492,7 @@ GitLab 在以下情况下最多创建四个分支和标记管道
`types` 已弃用，可能会在未来版本中删除。 `types` 已弃用，可能会在未来版本中删除。
使用 [`stages`](#stages) 代替。 使用 [`stages`](#stages) 代替。
### 作业定义的`type` ### 流水线任务定义的`type`
警告： 警告：
`type` 已弃用，可能会在未来版本之一中删除。 `type` 已弃用，可能会在未来版本之一中删除。
......