控制作业如何运行

在新的流水线开始之前，极狐GitLab 会检查流水线配置以确定哪些作业可以在该流水线中运行。您可以根据变量的值或流水线类型等条件使用 rules 配置作业的运行。

创建必须手动运行的作业#

您可以要求作业在用户启动之前不运行，这称为 手动作业。您可能希望将手动作业用于诸如部署到生产环境之类的操作。

要将作业指定为手动作业，请在 .gitlab-ci.yml 文件中将 when: manual 添加到作业中。

默认情况下，当流水线启动时，手动作业显示为跳过。

您可以使用 受保护的分支 更严格地 保护手动部署 以防止未经授权的用户运行。

手动作业的类型#

手动作业可以是可选的或阻塞的。

在可选手动作业中：

• allow_failure 是 true，这是定义在 rules 外的 when: manual 作业的默认设置。
• 状态不会影响整体流水线状态。即使所有手动作业都失败，流水线也可以成功。

在阻塞手动作业中：

• allow_failure 是 false，这是定义在 rules 内的 when: manual 作业的默认设置。
• 流水线将在定义作业的阶段停止。要让流水线继续运行，请 运行手动作业。
• 在启用 流水线必须成功 的项目中，合并请求不能与阻塞的流水线合并。
• 流水线显示状态为 blocked。

在使用带有 strategy: depend 的手动作业时，手动作业的类型会影响流水线运行时触发作业的状态。

运行手动作业#

要运行手动作业，您必须有权限合并到分配的分支：

1. 转到流水线、作业、环境 或部署视图。
2. 在手动作业旁边，选择 Run (
   )。

指定运行手动作业时的变量#

运行手动作业时，您可以提供额外的作业特定变量。

您可以从要运行的手动作业的作业页面提供附加变量。要访问此页面，请在流水线视图中选择手动作业的 名称，而不是 Run (

)。

在此定义 CI/CD 变量，以便在使用 CI/CD 变量 的作业中更改执行。

如果您添加的变量已在 CI/CD 设置或 .gitlab-ci.yml 文件中定义，则该 变量将被覆盖 为新值。使用此过程覆盖的任何变量都将被 展开 而不 遮蔽。

为手动作业添加确认对话框#

使用 manual_confirmation 和 when: manual 为手动作业添加确认对话框。确认对话框有助于防止意外部署或删除，尤其是对于那些部署到生产环境的敏感作业。

在手动作业运行之前，用户会被提示确认操作，这提供了额外的安全性和控制。

保护手动作业#

使用 受保护的环境 来定义授权运行手动作业的用户列表。您只能授权与受保护环境相关联的用户触发手动作业，这可以：

• 更精确地限制谁可以部署到环境。
• 阻止流水线，直到获得批准的用户“批准”它。

要保护手动作业：

1. 向作业添加 environment。例如：

   yaml
   1deploy_prod:
   2  stage: deploy
   3  script:
   4    - echo "Deploy to production server"
   5  environment:
   6    name: production
   7    url: https://example.com
   8  when: manual
   9  rules:
   10    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

2. 在 受保护的环境设置 中，选择环境（在此示例中为 production）并将授权触发手动作业的用户、角色或群组添加到 Allowed to Deploy 列表中。只有在此列表中的用户以及极狐GitLab 管理员才能使用受保护的环境。

您可以将受保护的环境与阻塞手动作业结合使用，以拥有一份允许批准后续流水线阶段的用户列表。将 allow_failure: false 添加到受保护的手动作业中，并且只有在授权用户触发手动作业后，流水线的下一阶段才会运行。

延迟运行作业#

使用 when: delayed 在等待期后执行脚本，或如果您希望避免作业立即进入 pending 状态。

您可以使用 start_in 关键字设置时间段。start_in 的值是经过的时间（以秒为单位），除非提供了单位。最小值为一秒，最大值为一周。有效值的示例包括：

• '5'（没有单位的值必须用单引号括起来）
• 5 seconds
• 30 minutes
• 1 day
• 1 week

当一个阶段包含延迟作业时，流水线在延迟作业完成之前不会继续。您可以使用此关键字在不同阶段之间插入延迟。

延迟作业的计时器在上一阶段完成后立即启动。与其他类型的作业相似，延迟作业的计时器不会在上一阶段通过之前启动。

以下示例创建一个名为 timed rollout 10% 的作业，该作业在上一阶段完成后 30 分钟执行：

yaml
1timed rollout 10%:
2  stage: deploy
3  script: echo 'Rolling out 10% ...'
4  when: delayed
5  start_in: 30 minutes
6  environment: production

要停止延迟作业的活动计时器，请选择 Unschedule (

)。此作业将不再能够自动调度运行。但是，您可以手动执行该作业。

要手动启动延迟作业，请选择 Unschedule (

) 以停止延迟计时器，然后选择 Run ()。很快，极狐GitLab Runner 会启动作业。

并行化大型作业#

要将大型作业拆分为多个并行运行的小型作业，请在 .gitlab-ci.yml 文件中使用 parallel 关键字。

不同的语言和测试套件有不同的方法来启用并行化。例如，使用 Semaphore Test Boosters 和 RSpec 并行运行 Ruby 测试：

ruby
# Gemfile
source 'https://rubygems.org'

gem 'rspec'
gem 'semaphore_test_boosters'

yaml
test:
  parallel: 3
  script:
    - bundle
    - bundle exec rspec_booster --job $CI_NODE_INDEX/$CI_NODE_TOTAL

然后，您可以转到新流水线构建的 Jobs 选项卡，查看您的 RSpec 作业拆分为三个独立的作业。

运行一个一维矩阵的并行作业#

要在单个流水线中多次并行运行作业，但每个作业实例具有不同的变量值，请使用 parallel:matrix 关键字：

yaml
1deploystacks:
2  stage: deploy
3  script:
4    - bin/deploy
5  parallel:
6    matrix:
7      - PROVIDER: [aws, ovh, gcp, vultr]
8  environment: production/$PROVIDER

运行并行触发作业的矩阵#

您可以在单个流水线中多次并行运行 触发 作业，但每个作业实例具有不同的变量值。

yaml
1deploystacks:
2  stage: deploy
3  trigger:
4    include: path/to/child-pipeline.yml
5  parallel:
6    matrix:
7      - PROVIDER: aws
8        STACK: [monitoring, app1]
9      - PROVIDER: ovh
10        STACK: [monitoring, backup]
11      - PROVIDER: [gcp, vultr]
12        STACK: [data]

此示例生成 6 个并行 deploystacks 触发作业，每个作业具有不同的 PROVIDER 和 STACK 值，并且它们使用这些变量创建 6 个不同的子流水线。

plaintext
1deploystacks: [aws, monitoring]
2deploystacks: [aws, app1]
3deploystacks: [ovh, monitoring]
4deploystacks: [ovh, backup]
5deploystacks: [gcp, data]
6deploystacks: [vultr, data]

为每个并行矩阵作业选择不同的 runner 标签#

您可以将定义在 parallel: matrix 中的变量与 tags 关键字结合使用，以实现动态 runner 选择：

yaml
1deploystacks:
2  stage: deploy
3  script:
4    - bin/deploy
5  parallel:
6    matrix:
7      - PROVIDER: aws
8        STACK: [monitoring, app1]
9      - PROVIDER: gcp
10        STACK: [data]
11  tags:
12    - ${PROVIDER}-${STACK}
13  environment: $PROVIDER/$STACK

从 parallel:matrix 作业中获取产物#

您可以通过使用 dependencies 关键字从使用 parallel:matrix 创建的作业中获取产物。使用作业名称作为 dependencies 的值，格式为字符串：

plaintext
<job_name> [<matrix argument 1>, <matrix argument 2>, ... <matrix argument N>]

例如，要从 RUBY_VERSION 为 2.7 且 PROVIDER 为 aws 的作业中获取产物：

yaml
1ruby:
2  image: ruby:${RUBY_VERSION}
3  parallel:
4    matrix:
5      - RUBY_VERSION: ["2.5", "2.6", "2.7", "3.0", "3.1"]
6        PROVIDER: [aws, gcp]
7  script: bundle install
8
9deploy:
10  image: ruby:2.7
11  stage: deploy
12  dependencies:
13    - "ruby: [2.7, aws]"
14  script: echo hello
15  environment: production

dependencies 条目需要加上引号。

使用多个并行化作业的 needs 指定并行化作业#

您可以使用 needs:parallel:matrix 中定义的变量与多个并行化作业一起使用。

例如：

yaml
1linux:build:
2  stage: build
3  script: echo "Building linux..."
4  parallel:
5    matrix:
6      - PROVIDER: aws
7        STACK:
8          - monitoring
9          - app1
10          - app2
11
12mac:build:
13  stage: build
14  script: echo "Building mac..."
15  parallel:
16    matrix:
17      - PROVIDER: [gcp, vultr]
18        STACK: [data, processing]
19
20linux:rspec:
21  stage: test
22  needs:
23    - job: linux:build
24      parallel:
25        matrix:
26          - PROVIDER: aws
27            STACK: app1
28  script: echo "Running rspec on linux..."
29
30mac:rspec:
31  stage: test
32  needs:
33    - job: mac:build
34      parallel:
35        matrix:
36          - PROVIDER: [gcp, vultr]
37            STACK: [data]
38  script: echo "Running rspec on mac..."
39
40production:
41  stage: deploy
42  script: echo "Running production..."
43  environment: production

此示例生成多个作业。每个并行作业具有不同的 PROVIDER 和 STACK 值。

• 3 个并行 linux:build 作业：
  • linux:build: [aws, monitoring]
  • linux:build: [aws, app1]
  • linux:build: [aws, app2]
• 4 个并行 mac:build 作业：
  • mac:build: [gcp, data]
  • mac:build: [gcp, processing]
  • mac:build: [vultr, data]
  • mac:build: [vultr, processing]
• 一个 linux:rspec 作业。
• 一个 production 作业。

作业有三个执行路径：

• Linux 路径：linux:rspec 作业在 linux:build: [aws, app1] 作业完成后立即运行，而无需等待 mac:build 完成。
• macOS 路径：mac:rspec 作业在 mac:build: [gcp, data] 和 mac:build: [vultr, data] 作业完成后立即运行，而无需等待 linux:build 完成。
• production 作业在所有先前作业完成后立即运行。