エンドツーエンドのテストパイプライン

e2e:package-and-test

e2e:package-and-test 子パイプラインは、GitLab プラットフォームの E2E テストの主な Executor です。パイプライン定義には、マージリクエストパイプラインで実行されるテストの数を減らすための動的なコンポーネントがいくつかあります。

セットアップ

パイプラインのセットアップ：

  • メイン GitLab パイプラインのprepare ステージにあるe2e-test-pipeline-generate ジョブ。
  • qa ステージのe2e:package-and-test ジョブは、omnibus パッケージのビルドと E2E テストの実行を担当する子パイプラインをトリガーします。

e2e-test-pipeline-generate

このジョブは、選択的テスト実行を実装する 2 つのコンポーネントから成ります：

  • detect_changes Rake タスクは、特定のマージリクエストパイプラインでどの e2e spec を実行すべきかを決定します。このタスクは特定のマージリクエストの変更を分析し、どの spec を実行しなければならないかを決定します。それに基づいて、すべてのシナリオの dry-run が実行され、シナリオに実行可能なテストが含まれているかどうかが判断されます。選択的テスト実行は、これらの基準を使用して、実行する特定のテストを決定します。
  • generate-e2e-pipeline が実行され、適切な環境変数が設定された子パイプラインの YAML 定義ファイルが生成されます。

e2e:package-and-test

E2E テスト実行パイプラインは、E2E テストの実行をサポートする複数のステージで構成されています。

.pre

このステージは以下のタスクを担当します：

テスト

このステージでは、異なるタイプのGitLab設定に対してe2eテストを実行します。実行されるジョブの数はe2e-test-pipeline-generate ジョブによって動的に決定されます。

レポーター

このステージはアリュールテストのレポート作成を担当します。

新しいジョブの追加

選択的テストの実行は、すべてのジョブ定義に存在する一連のルールに依存します。典型的なジョブには以下のような属性があります：

variables:
  QA_SCENARIO: Test::Integration::MyNewJob
rules:
  - !reference [.rules:test:qa, rules]
  - if: $QA_SUITES =~ /Test::Integration::MyNewJob/
  - !reference [.rules:test:manual, rules]

この例では:

  • QA_SCENARIO: Test::Integration::MyNewJob gitlab-qa Executor に渡されるシナリオクラスの名前。
  • !reference [.rules:test:qa, rules]すべてのテストを実行するパイプラインにマッチする主なルール定義。例えば、qa フレームワークに変更があった場合など。

  • if: $QA_SUITES =~ /Test::Integration::MyNewJob/ QA_SUITE は、qa framework にあるシナリオ抽象化の名前です。

    QA_SUITE gitlab-qa の Executor に渡されるQA_SCENARIO とは異なります。QA_SUITE 抽象クラスには、通常、どのタグを実行するかという情報と、オプションでいくつかの追加セットアップ ステップが含まれます。

  • !reference [.rules:test:manual, rules]選択的テスト実行によって実行するように設定されていなくても、要求があれば実行できるように、ジョブをmanual に設定します。

上記の例を考慮して、新しいジョブを作成するために以下のステップを実行してください：

  1. gitlab-qa プロジェクトのintegration ディレクトリに新しいシナリオタイプmy_new_job.rb を作成し、新しいバージョンをリリースします。

  2. qa フレームワークのintegration ディレクトリに新しいシナリオmy_new_job.rb を作成します。最も単純なケースでは、このシナリオは実行されるべきRSpecタグを定義します：

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

  3. main.gitlab-ci.yml パイプライン定義に新しいジョブ定義を追加します：

    ee:my-new-job:
  extends: .qa
  variables:
    QA_SCENARIO: Test::Integration::MyNewJob
  rules:
    - !reference [.rules:test:qa, rules]
    - if: $QA_SUITES =~ /Test::Integration::MyNewJob/
    - !reference [.rules:test:manual, rules]

Parallels ジョブ

複数の並列ジョブを実行する必要があるジョブタイプで選択実行を正しく動作させるためには、ジョブ定義を並列ジョブと選択実行に分割する必要があります。分割は、選択実行が単一の仕様のみを実行するときに、複数の不要なジョブが生成されないようにするために必要です。例えば

ee:my-new-job-selective:
  extends: .qa
  variables:
    QA_SCENARIO: Test::Integration::MyNewJob
  rules:
    - !reference [.rules:test:qa-selective, rules]
    - if: $QA_SUITES =~ /Test::Integration::MyNewJob/
ee:my-new-job:
  extends:
    - .parallel
    - ee:my-new-job-selective
  rules:
    - !reference [.rules:test:qa-parallel, rules]
    - if: $QA_SUITES =~ /Test::Integration::MyNewJob/

e2e:test-on-gdk

e2e:test-on-gdk 子パイプラインは、e2e:package-and-test やレビューアプリを経由するよりも速くエンドツーエンドのテスト実行に関するフィードバックをエンジニアに提供することで、GitLab プラットフォームの開発をサポートします。

これは、Omnibus GitLabに対してテストするよりも短時間でビルドとインストールができるGitLab Development Kit (GDK)に対してテストを実行することで実現できます。GDKは開発環境ですが、Omnibus GitLabは本番環境のデプロイに使えるというトレードオフがあります。GDKに対して実行されるテストは、アセットを事前にコンパイルしたり、公式のインストール・パッケージの一部として設定デフォルトを割り当てたり、GitLabサービスを複数のサーバーにデプロイしたりなど、GitLabを本番環境で実行するための準備プロセスの一部に依存するバグを捕捉できないかもしれません。一方、GDKを毎日使用するエンジニアは、GDKにのみ現れるバグを自動化されたテストが捕らえるという恩恵を受けることができます。

セットアップ

パイプラインのセットアップは、メインのGitLabパイプラインのいくつかのジョブで構成されています：

build-gdk-image

このジョブはマージリクエストのコードを使用して、テストジョブで使用できるDockerイメージを構築し、コンテナ内でGDKインスタンスを起動します。イメージはコンテナレジストリにプッシュされます。

このジョブはデフォルトブランチ上のパイプラインでも実行され、GDKとGitLabコンポーネントを含むベースイメージを構築します。これにより、マージリクエストでイメージ全体を一から構築する必要がなくなります。しかし、マージリクエストに特定の GitLab コンポーネントやコードへの変更が含まれている場合、ジョブはテストジョブで使うイメージをビルドする前にベースイメージを再構築します。

e2e:test-on-gdk 子パイプライン

e2e:package-and-test パイプラインと同様に、e2e:test-on-gdk パイプラインは、E2E テストの実行をサポートする複数のステージで構成されます。

.pre

このステージは、並列テスト実行をサポートするknapsack レポートの取得を担当します。

テスト

このステージでは、異なるタイプのGitLab設定に対してe2eテストを実行します。実行されるジョブの数はe2e-test-pipeline-generate ジョブによって動的に決定されます。

各ジョブはbuild-gdk-image ジョブで作成された GDK Docker イメージからコンテナを起動し、コンテナ内で実行されている GDK インスタンスに対してエンドツーエンドのテストを実行します。

レポーター

このステージはアリュールテストのレポート作成を担当します。