Help us learn about your current experience with the documentation. Take the survey.

端到端测试流水线

常见架构

所有 E2E 测试都在独立的子流水线中执行。为了支持 E2E 测试流水线的不同动态特性，所有子流水线 YAML 文件都由 e2e-test-pipeline-generate CI/CD 作业生成，并由相应的触发作业触发。

e2e-test-pipeline-generate

e2e-test-pipeline-generate 作业生成 CI/CD YAML 文件定义，用于触发运行 E2E 测试的子流水线。

generate_e2e_pipelines Rake 任务：

  1. 为特定的合并请求流水线确定应执行哪些 e2e 规范。
  2. 为每种 E2E 测试流水线类型生成 CI/CD YAML 文件定义。

此 Rake 任务：

  1. 分析特定合并请求中的更改，并使用这些标准通过选择性测试执行确定必须执行哪些规范。基于此，每个场景都会执行一次 dry-run，并确定场景是否包含任何可执行测试。
  2. 计算每个场景的总运行时间。
  3. 基于运行时间值，动态作业扩展计算每种场景类型所需的并行 CI/CD 作业数量，并生成具有适当值的流水线 YAML 文件。

e2e:perf-on-cng

e2e:perf-on-cng 子流水线针对 Cloud Native GitLab 安装运行测试。

部署由 orchestrator CLI 工具管理，您也可以使用它来本地重现 CI/CD 部署。

e2e:perf-on-cng 子流水线在合并请求中执行，是一个非阻塞作业。如果任何测试失败，它不会阻止您的合并请求被合并。

设置

此 E2E 测试子流水线由 e2e:perf-on-cng 作业触发，使用存储在 e2e-test-pipeline-generate CI/CD 作业中的动态生成的 CI/CD YAML 文件作为工件。CI/CD YAML 文件是使用模板生成的。

子流水线作业

子流水线包含几个支持 E2E 测试执行的阶段。

.pre

  • build-cng-env 作业负责为 CNG 下游流水线设置所有环境变量
  • build-cng 作业触发 CNG 下游流水线，负责构建所有必要的镜像

准备

  • dotenv-vars 作业负责从包含所有 k6 性能测试的 qa/performance_test 文件夹创建工件。此工件将被下游流水线作业下载以运行测试。它还存储一些环境变量，如 CI_JOB_NAME、CI_JOB_ID 和 GITLAB_HELM_CHART_REF，如作业定义中所示，这些变量将被 run-performance-tests 作业使用

测试

run-performance-test 作业

此作业在 Component Performance testing 项目中触发下游多项目流水线。此流水线执行以下操作：

  1. 在同一区域和可用区创建两个 GPC 实例。
    1. server 实例：使用 orchestrator 创建 GitLab 的 CNG 实例
      1. 使用 kind 设置本地 k8s 集群
      2. 使用官方 helm chart 安装 GitLab
    2. test runner 实例：运行从 dotenv-vars 作业下载为工件的 k6 测试，并在服务器实例上创建的 CNG GitLab 实例上运行它们。

故障排除

有时，run-performance-test 作业下的多项目作业在数据播种期间可能因 gem 不兼容错误而失败。

错误示例如下：

/usr/lib/ruby/gems/3.3.0/gems/bundler-2.6.9/lib/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:225:in `resolve_conflict': Could not find compatible versions (Bundler::PubGrub::SolveFailure)
Because every version of gitlab-backup-cli depends on grpc ~> 1.74.0
  and Gemfile depends on gitlab-backup-cli >= 0,
  grpc ~> 1.74.0 is required.

这可能是因为 Gemfile 有更新，但您的合并请求中不包含这些更新。将合并请求分支与 master 分支进行变基应该可以解决这个问题。

e2e:test-on-cng

e2e:test-on-cng 子流水线针对 Cloud Native GitLab 安装运行测试。

部署由 orchestrator CLI 工具管理，您也可以使用它来本地重现 CI/CD 部署。

e2e:test-on-cng 子流水线在合并请求中执行，是合并前验证生命周期的一部分。如果任何测试失败，您无法合并引入的代码更改。

设置

此 E2E 测试子流水线由 e2e:test-on-cng 作业触发，使用存储在 e2e-test-pipeline-generate CI/CD 作业中的动态生成的 CI/CD YAML 文件作为工件。CI/CD YAML 文件是使用模板生成的。

子流水线作业

子流水线包含几个支持 E2E 测试执行的阶段。

.pre

  • build-cng-env 作业负责为 CNG 下游流水线设置所有环境变量
  • build-cng 作业触发 CNG 下游流水线，负责构建所有必要的镜像

测试

test 阶段中的作业执行以下操作：

  1. 使用 kind 设置本地 k8s 集群
  2. 使用官方 helm chart 安装 GitLab
  3. 对已执行的部署执行 E2E 测试
报告

此阶段负责 allure 测试报告 的生成。

调试

为了帮助调试：

  • 每个测试作业都会打印一个参数列表，您可以将这些参数传递给 orchestrator 以精确重现相同的部署用于本地调试。
  • 集群事件日志和所有 pod 日志都保存在 E2E 测试作业工件中。
  • 在部署失败的情况下，orchestrator 会自动输出所有带有错误的集群事件。

e2e:test-on-omnibus-ee

e2e:test-on-omnibus-ee 子流水线针对 Omnibus 安装运行测试。默认情况下，此流水线类型不会在合并请求流水线中执行，但可以通过手动触发 e2e:test-on-omnibus-ee 作业来触发。

此流水线类型允许失败，即使在合并请求流水线中手动触发的情况下，失败的测试也不会阻止合并的能力。

Linux 包部署由 gitlab-qa 管理。

设置

此 E2E 测试子流水线由 e2e:test-on-omnibus-ee 作业触发，使用存储在 e2e-test-pipeline-generate CI/CD 作业中的动态生成的 CI/CD YAML 文件作为工件。CI/CD YAML 文件是使用模板生成的。

子流水线作业

E2E 测试执行流水线包含几个阶段，所有阶段都支持 E2E 测试的执行。

.pre

此阶段负责以下任务：

测试

test 阶段中的作业执行以下操作：

  1. 使用构建的 Linux 包安装 GitLab。
  2. 针对 Linux 包安装执行 E2E 测试。

报告

此阶段负责 allure 测试报告 的生成。

e2e:test-on-gdk

e2e:test-on-gdk 子流水线通过向工程师提供比通过 e2e:test-on-omnibus-ee 更快的端到端测试执行反馈，来支持 GitLab 平台的开发。

这是通过针对 GitLab Development Kit (GDK) 运行测试来实现的，构建和安装 GDK 所需的时间比测试 Omnibus GitLab 更短。

权衡在于，Omnibus GitLab 可用于部署生产环境安装，而 GDK 是一个开发环境。针对 GDK 运行的测试可能无法捕获依赖于准备 GitLab 在生产环境中运行的部分过程的错误，包括预编译资源、作为官方安装包一部分分配配置默认值、将 GitLab 服务部署到多台服务器等等。另一方面，日常使用 GDK 的工程师可以从自动化测试中受益，这些测试能够捕获仅在 GDK 上出现的错误。

设置

此 E2E 测试子流水线由 e2e:test-on-gdk 作业触发，使用存储在 e2e-test-pipeline-generate CI/CD 作业中的动态生成的 CI/CD YAML 文件作为工件。CI/CD YAML 文件是使用模板生成的。

build-gdk-image

The build-gdk-image job 使用合并请求中的代码构建 Docker 镜像，该镜像可用于测试作业中以在容器中启动 GDK 实例。该镜像被推送到容器注册表。

该作业还在默认分支的流水线中运行，以构建包含 GDK 和 GitLab 组件的基础镜像。这避免了在合并请求中从头开始构建整个镜像。但是，如果合并请求包含对某些 GitLab 组件或代码的更改，该作业将在构建用于测试作业的镜像之前重建基础镜像。

子流水线作业

子流水线包含几个支持 E2E 测试执行的阶段。

测试

test 阶段中的作业执行以下操作：

  1. 使用由 build-gdk-image 作业构建的 Docker 镜像启动 GDK 实例。
  2. 针对正在运行的 GDK 实例运行 E2E 测试。

报告

此阶段负责 allure 测试报告 的生成。

测试许可证

有关这些流水线使用的许可证的更多信息，请参见 test licenses。

向 E2E 测试流水线添加新作业

E2E 测试流水线使用基于运行时的动态作业扩展。为了在流水线定义 YAML 文件中的作业定义和特定测试场景之间创建映射，使用了 scenario 类。这些类位于 qa/qa/scenario 文件夹中。

e2e 测试流水线定义 YAML 文件中的一个典型作业定义如下所示：

my-new-test-job:
  # ...
  variables:
    QA_SCENARIO: Test::Integration::MyNewTestScenario

在此示例中：

  • QA_SCENARIO: Test::Integration::MyNewTestScenario: 传递给 qa/bin/qa 测试执行脚本的场景类名称。虽然完整的类名是 QA::Scenario::Test:Integration::MyNewTestScenario，但省略了 QA::Scenario 以获得更简短的定义。

考虑到上述示例，请执行以下步骤来创建新作业：

  1. 在 e2e 测试框架的 integration 目录中创建新场景 my_new_job.rb。场景类应定义一个流水线映射，将场景与特定流水线类型中的特定作业关联起来。如果作业添加到 test-on-cng 流水线，此场景将定义应执行的 RSpec 标签和流水线映射：

    module QA
  module Scenario
    module Test
      module Integration
        class MyNewJob < Test::Instance::All
          tags :some_special_tag

          pipeline_mappings test_on_cng: %w[my-new-test-job]
        end
      end
    end
  end

  2. 在 main.gitlab-ci.yml 流水线定义中添加新作业定义：

    my-new-test-job:
  extends:
    - .cng-test
  variables:
    QA_SCENARIO: Test::Integration::MyNewTestScenario

这样的定义确保 my-new-test-job 具有基于预定义运行时间阈值的自动并行作业扩展。