控制作业如何运行

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

创建必须手动执行的作业

您可以要求某个作业不需要运行除非有用户启动它。这称之为 手动作业。您可能想要在某些场景下使用手动作业，例如部署到生产环境。

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

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

您可以使用受保护的分支来更严格地保护手动作业，以实现该流水线不会被未经授权的用户运行。

手动作业的类型

手动作业要么是可选的，要么是被阻塞。

在可选的手动作业中：

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

在阻塞的手动作业中：

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

When using manual jobs in triggered pipelines with strategy: depend, the type of manual job can affect the trigger job’s status while the pipeline runs.

运行手动作业

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

前往流水线、作业、环境或部署视图。
在手动作业旁边，选择运行 ()。

您还可以在运行手动作业时添加自定义 CI/CD 变量。

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

使用 manual_confirmation 和 when: manual 来为手动作业添加确认对话框。确认对话框能够帮助阻止意外部署或删除，特别是那些部署到生产环境的手动作业。

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

保护手动作业（PREMIUM ALL）

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

更精确的限制谁可以部署到环境上。
阻止流水线，直到有资格的用户“批准”它。

要保护手动作业：

为作业添加一个 environment。例如：

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment:
    name: production
    url: https://example.com
  when: manual
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

在受保护的环境设置中，选择环境（本例中为 production），添加授权触发手动作业的用户、角色或群组，到 允许部署 列表。只有此列表中的人，以及始终能够使用受保护环境的 GitLab 管理员，才能触发此手动作业。

您可以使用受保护的环境和阻塞的手动作业来有一个允许批准后续流水线阶段的用户列表。添加 allow_failure: false 到受保护的手动作业，只有当手动作业被授权用户触发后，流水线的下一个阶段才会运行。

部署之后运行作业

使用 when: delayed 来在等待时间后或者您想避免作业立即进入 pending 状态后执行脚本。

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

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

当 stage 包含延迟作业时，流水线不会继续，直到延迟作业完成。您可以使用此关键字在不同的 stage 之间插入延迟。

延迟作业的定时器在上一个 stage 完成后立即开始。与其它类型的作业类似，延迟作业的定时器在上一个 stage 通过后才开始。

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

timed rollout 10%:
  stage: deploy
  script: echo 'Rolling out 10% ...'
  when: delayed
  start_in: 30 minutes
  environment: production

要停止延迟作业的活动计时器，选择取消 ()。此作业将不再自动运行。但是，您可以手动执行该作业。

要手动启动延迟作业，选择取消 () 停止延迟计时器，然后选择运行 ()。不久，极狐GitLab Runner 将启动作业。

并行化大型作业

要将大型作业分割成多个小型作业以便并行运行，可使用 .gitlab-ci.yml 文件中的 parallel 关键字来实现并行运行。

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

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

gem 'rspec'
gem 'semaphore_test_boosters'

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

然后你就可以前往流水线构建的作业选项卡，看到 RSpec 作业被分割成三个单独的作业。

Test Boosters 会向作者报告使用统计信息。

运行一维并行作业矩阵

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

deploystacks:
  stage: deploy
  script:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: [aws, ovh, gcp, vultr]
  environment: production/$PROVIDER

运行一组并行触发作业

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

deploystacks:
  stage: deploy
  trigger:
    include: path/to/child-pipeline.yml
  parallel:
    matrix:
      - PROVIDER: aws
        STACK: [monitoring, app1]
      - PROVIDER: ovh
        STACK: [monitoring, backup]
      - PROVIDER: [gcp, vultr]
        STACK: [data]

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

deploystacks: [aws, monitoring]
deploystacks: [aws, app1]
deploystacks: [ovh, monitoring]
deploystacks: [ovh, backup]
deploystacks: [gcp, data]
deploystacks: [vultr, data]

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

您可以使用在 parallel: matrix 中定义的变量与 tags 关键字进行动态 runner 选择：

deploystacks:
  stage: deploy
  script:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: aws
        STACK: [monitoring, app1]
      - PROVIDER: gcp
        STACK: [data]
  tags:
    - ${PROVIDER}-${STACK}
  environment: $PROVIDER/$STACK

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

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

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

比如，要从 RUBY_VERSION 为 2.7 和 PROVIDER 为 aws 的作业中获取产物，您可以这样写：

ruby:
  image: ruby:${RUBY_VERSION}
  parallel:
    matrix:
      - RUBY_VERSION: ["2.5", "2.6", "2.7", "3.0", "3.1"]
        PROVIDER: [aws, gcp]
  script: bundle install

deploy:
  image: ruby:2.7
  stage: deploy
  dependencies:
    - "ruby: [2.7, aws]"
  script: echo hello
  environment: production

dependencies 条目上的引号为必须。

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

引入于极狐16.3。

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

比如：

linux:build:
  stage: build
  script: echo "Building linux..."
  parallel:
    matrix:
      - PROVIDER: aws
        STACK:
          - monitoring
          - app1
          - app2

mac:build:
  stage: build
  script: echo "Building mac..."
  parallel:
    matrix:
      - PROVIDER: [gcp, vultr]
        STACK: [data, processing]

linux:rspec:
  stage: test
  needs:
    - job: linux:build
      parallel:
        matrix:
          - PROVIDER: aws
            STACK: app1
  script: echo "Running rspec on linux..."

mac:rspec:
  stage: test
  needs:
    - job: mac:build
      parallel:
        matrix:
          - PROVIDER: [gcp, vultr]
            STACK: [data]
  script: echo "Running rspec on mac..."

production:
  stage: deploy
  script: echo "Running production..."
  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 作业在所有先前作业完成后立即运行。

控制作业如何运行

创建必须手动执行的作业

手动作业的类型

运行手动作业

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

保护手动作业 （PREMIUM ALL）

部署之后运行作业

并行化大型作业

运行一维并行作业矩阵

运行一组并行触发作业

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

从 parallel:matrix 作业中获取产物

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

保护手动作业（PREMIUM ALL）

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