{{< details >}}

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

{{< /details >}}

使用 workflow 关键字来控制何时创建流水线。

workflow 关键字在作业之前进行评估。例如,如果某个作业被配置为在标签时运行,但工作流阻止标签流水线,则该作业永远不会运行。

workflow:rules 的常用 if 子句

以下是 workflow: rules 的一些示例 if 子句:

示例规则 详情
if: '$CI_PIPELINE_SOURCE == "merge_request_event"' 控制合并请求流水线的运行时间。
if: '$CI_PIPELINE_SOURCE == "push"' 控制分支流水线和标签流水线的运行时间。
if: $CI_COMMIT_TAG 控制标签流水线的运行时间。
if: $CI_COMMIT_BRANCH 控制分支流水线的运行时间。

查看 common if clauses for rules 以获取更多示例。

workflow: rules 示例

在以下示例中:

  • 对于所有 push 事件(分支更改和新标签)运行流水线。
  • 提交消息以 -draft 结尾的 push 事件流水线不运行,因为它们被设置为 when: never
  • 计划或合并请求的流水线也不运行,因为没有规则对它们评估为真。
workflow:
  rules:
    - if: $CI_COMMIT_MESSAGE =~ /-draft$/
      when: never
    - if: $CI_PIPELINE_SOURCE == "push"

此示例有严格的规则,流水线在任何其他情况下都运行。

或者,所有规则都可以是 when: never,并有一个最终的 when: always 规则。与 when: never 规则匹配的流水线不运行。所有其他流水线类型运行。例如:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - if: $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always

此示例阻止计划的流水线或 push(分支和标签)流水线。最后的 when: always 规则运行所有其他流水线类型,包括合并请求流水线。

在分支流水线和合并请求流水线之间切换

要在创建合并请求后使流水线从分支流水线切换到合并请求流水线,请在 .gitlab-ci.yml 文件中添加 workflow: rules 部分。

如果您同时使用两种流水线类型,重复流水线 可能会同时运行。为了防止重复流水线,请使用 CI_OPEN_MERGE_REQUESTS 变量

以下示例适用于仅运行分支和合并请求流水线的项目,但不运行其他任何情况的流水线。它运行:

  • 当分支没有打开合并请求时的分支流水线。
  • 当分支有打开合并请求时的合并请求流水线。
workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never
    - if: $CI_COMMIT_BRANCH

如果极狐GitLab尝试触发:

  • 合并请求流水线,则启动流水线。例如,可以通过推送到关联有打开合并请求的分支来触发合并请求流水线。
  • 分支流水线,但该分支有打开的合并请求,则不运行分支流水线。例如,可以通过对分支的更改、API 调用、计划的流水线等触发分支流水线。
  • 分支流水线,但分支没有打开合并请求,则运行分支流水线。

您还可以向现有的 workflow 部分添加规则,以在创建合并请求时从分支流水线切换到合并请求流水线。

将此规则添加到 workflow 部分的顶部,然后是已经存在的其他规则:

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - # Previously defined workflow rules here

触发的流水线 在分支上运行时会设置 $CI_COMMIT_BRANCH,并可能被类似的规则阻止。触发的流水线具有 triggerpipeline 的流水线来源,因此 && $CI_PIPELINE_SOURCE == "push" 确保规则不会阻止触发的流水线。

Git Flow 与合并请求流水线

您可以使用 workflow: rules 与合并请求流水线。通过这些规则,您可以在保持支持多个软件版本的长期分支的同时,使用 合并请求流水线功能 与特性分支。

例如,仅为您的合并请求、标签和受保护分支运行流水线:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_TAG
    - if: $CI_COMMIT_REF_PROTECTED == "true"

此示例假设您的长期分支是 受保护的

跳过草稿合并请求的流水线

您可以使用 workflow: rules 跳过草稿合并请求的流水线。通过这些规则,您可以避免在开发完成之前使用计算分钟。

例如,以下规则将禁用标题中包含 [Draft](Draft)Draft: 的合并请求的 CI 构建:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TITLE =~ /^(\[Draft\]|\(Draft\)|Draft:)/
      when: never

stages:
  - build

build-job:
  stage: build
  script:
    - echo "Testing"

workflow:rules 模板(已弃用)

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

workflow:rules 模板在极狐GitLab 17.0 中已被弃用,计划在 18.0 中删除。此更改是重大更改。要在您的流水线中配置 workflow:rules,请明确添加关键字。有关选项,请参见上面的示例。

{{< /alert >}}

极狐GitLab 提供了为常见场景设置 workflow: rules 的模板。这些模板有助于防止重复流水线。

Branch-Pipelines 模板 使您的流水线为分支和标签运行。

分支流水线状态显示在使用分支作为来源的合并请求中。但是,此流水线类型不支持 合并请求流水线 提供的任何功能,例如 合并结果流水线合并列车。此模板故意避免这些功能。

include 它:

include:
  - template: 'Workflows/Branch-Pipelines.gitlab-ci.yml'

MergeRequest-Pipelines 模板 使您的流水线为默认分支、标签和所有类型的合并请求流水线运行。如果您使用任何 合并请求流水线功能,请使用此模板。

include 它:

include:
  - template: 'Workflows/MergeRequest-Pipelines.gitlab-ci.yml'

故障排除

合并请求卡在 Checking pipeline status. 消息

如果合并请求显示 Checking pipeline status.,但消息从未消失(“旋转器”从未停止旋转),则可能是由于 workflow:rules 引起的。如果项目启用了 Pipelines must succeed,但 workflow:rules 阻止了合并请求的流水线运行,则可能会发生此问题。

例如,使用此工作流,合并请求无法合并,因为没有流水线可以运行:

workflow:
  rules:
    - changes:
        - .gitlab/**/**.md
      when: never