{{< details >}}

  • Tier: 基础版, 专业版, 旗舰版
  • Offering: JihuLab.com, 私有化部署

{{< /details >}}

在新的流水线开始之前，极狐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 ({{< icon name=”play” >}})。

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

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

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

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

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

The run manual job page with fields for specifying CI/CD variables.

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

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

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

保护手动作业

{{< details >}}

  • Tier: Premium, Ultimate
  • Offering: JihuLab.com, 极狐GitLab私有化部署, 极狐GitLab Dedicated

{{< /details >}}

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

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

要保护手动作业：

  1. 向作业添加 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

  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 分钟执行：

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

要停止延迟作业的活动计时器，请选择 Unschedule ({{< icon name=”time-out” >}})。此作业将不再能够自动调度运行。但是，您可以手动执行该作业。

要手动启动延迟作业，请选择 Unschedule ({{< icon name=”time-out” >}}) 以停止延迟计时器，然后选择 Run ({{< icon name=”play” >}})。很快，极狐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

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

{{< alert type=”warning” >}}

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

{{< /alert >}}

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

要在单个流水线中多次并行运行作业，但每个作业实例具有不同的变量值，请使用 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 指定并行化作业

{{< history >}}

  • 在极狐GitLab 16.3 中引入。

{{< /history >}}

您可以使用 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 作业在所有先前作业完成后立即运行。