特別な設定が必要なテストの実行

Jenkins仕様

jenkins_build_status_spec はJenkins GitLabプラグインがプリインストールされたDockerコンテナでJenkinsインスタンスを起動します。ライセンスの制限により、このイメージをディストリビューションすることはできません。QA互換のイメージをビルドするには、サードパーティのDockerfileがあるサードパーティイメージプロジェクトをご覧ください。このプロジェクトには、フォークしてCIで自動的にイメージをビルドする手順もあります。

フォークされたリポジトリの場所のための環境変数も必要です。

  • QA_THIRD_PARTY_DOCKER_REGISTRY (リポジトリ/画像がホストされているコンテナレジストリ、たとえばregistry.gitlab.com)
  • QA_THIRD_PARTY_DOCKER_REPOSITORY (イメージを保存するリポジトリの内部パス。例えばregistry.gitlab.com/<project path>)
  • QA_THIRD_PARTY_DOCKER_USER (このリポジトリのコンテナレジストリにアクセスできるユーザ名）。
  • QA_THIRD_PARTY_DOCKER_PASSWORD (このユーザー名で認証するためのパスワード/トークン)

テストはJenkinsのGitLabプラグインに、テストの実行に使われるGitLabインスタンスのURLを設定します。GitLabインスタンスとJenkinsの間には双方向のネットワークが必要なので、GitLabをDockerコンテナで起動することもできます。

ナイトリーイメージを元にGitLab用のDockerコンテナを起動するには：

docker run \
  --publish 80:80 \
  --name gitlab \
  --hostname localhost \
  --network test
  gitlab/gitlab-ee:nightly

/qa ディレクトリからテストを実行するには：

export QA_THIRD_PARTY_DOCKER_REGISTRY=<registry>
export QA_THIRD_PARTY_DOCKER_REPOSITORY=<repository>
export QA_THIRD_PARTY_DOCKER_USER=<user with registry access>
export QA_THIRD_PARTY_DOCKER_PASSWORD=<password for user>
export WEBDRIVER_HEADLESS=0
bin/qa Test::Instance::All http://localhost -- qa/specs/features/ee/browser_ui/3_create/jenkins/jenkins_build_status_spec.rb

テストは自動的にJenkins用のDockerコンテナを立ち上げ、テストが完了したらティアダウンします。

テスト以外でJenkinsを手動で実行する必要がある場合は、サードパーティのイメージプロジェクトのREADMEを参照してください。

トラブルシューティング

Jenkins Dockerコンテナがログに何も情報を提供せずに終了する場合は、Docker Engineで使用するメモリを増やしてみてください。

クラスターのテスト

:gitaly_ha とタグ付けされたテストは、Test::Integration::GitalyCluster GitLab QA シナリオによって設定・起動された Docker コンテナのセットに対してのみ実行できるオーケストレーションされたテストです。

前述のシナリオに関するドキュメントにあるように、以下のコマンドでテストを実行します：

gitlab-qa Test::Integration::GitalyCluster EE

しかし、テストの実行が終わるとコンテナは削除されます。さらにテストを行いたい場合、たとえば、デバッガを使用して単一のテストを実行したい場合は、 --no-tests オプション を使用すると、gitlab-qa でテストの実行をスキップし、コンテナを引き続き使用できるようにコンテナを実行したままにすることができます。

gitlab-qa Test::Integration::GitalyCluster EE --no-tests

すべてのコンテナが実行されているとき、docker ps コマンドの出力は GitLab コンテナがどのポートからアクセスできるかを示します。例えば

CONTAINER ID   ...     PORTS                                    NAMES
d15d3386a0a8   ...     22/tcp, 443/tcp, 0.0.0.0:32772->80/tcp   gitlab-gitaly-cluster

これは、gitlab-gitaly-cluster コンテナで実行されている GitLab インスタンスにhttp://localhost:32772 経由でアクセスできることを示しています。しかし、クローンやプッシュのような Git のオペレーションは、クローン URL として UI に表示された URL に対して実行されます。これは、GitLabインスタンス用に設定されたホスト名を使用しており、この場合はDockerコンテナ名とネットワークのgitlab-gitaly-cluster.test 。テストを実行する前に、そのアドレス経由でコンテナにアクセスできるようにコンピュータを設定する必要があります。GDK に対してテストを実行するために説明したように、Caddy サーバーを使うという方法もあります。

もう1つの方法は、NGINXを使用することです。

どちらの場合も、gitlab-gitaly-cluster.test を適切な IP アドレスに変換するようにマシンを設定する必要があります：

echo '127.0.0.1 gitlab-gitaly-cluster.test' | sudo tee -a /etc/hosts

次にNGINXをインストールします：

# on macOS
brew install nginx

# on Debian/Ubuntu
apt install nginx

# on Fedora
yum install nginx

最後に、gitlab-gitaly-cluster.test のリクエストを GitLab インスタンスに渡すように NGINX を設定します：

# On Debian/Ubuntu, in /etc/nginx/sites-enabled/gitlab-cluster
# On macOS, in /usr/local/etc/nginx/nginx.conf

server {
  server_name gitlab-gitaly-cluster.test;
  client_max_body_size 500m;

  location / {
    proxy_pass http://127.0.0.1:32772;
    proxy_set_header Host gitlab-gitaly-cluster.test;
  }
}

NGINX を再起動して設定を有効にします。例えば

# On Debian/Ubuntu
sudo systemctl restart nginx

# on macOS
sudo nginx -s reload

/qa ディレクトリからテストを実行できます：

WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All http://gitlab-gitaly-cluster.test -- --tag gitaly_cluster

テストが終わったら、Dockerコンテナを停止して削除します：

docker stop gitlab-gitaly-cluster praefect postgres gitaly3 gitaly2 gitaly1
docker rm gitlab-gitaly-cluster praefect postgres gitaly3 gitaly2 gitaly1

ランナーが必要なテスト

Runnerを使用するテストをエラーなく実行するためには、GitLab Dockerインスタンスを作成する際に、Dockerrun コマンドの--hostname パラメータに特定のインターフェースIPアドレスか、Runnerコンテナからアクセス可能なループバックでないホスト名を指定する必要があります。GitLabのホスト名としてlocalhost （または127.0.0.1）を指定しても動作しません（GitLab RunnerがDockerネットワークをhostとして作成されていない限り）。

Runner を必要とするテストの例：

  • qa/qa/specs/features/ee/browser_ui/13_secure/create_merge_request_with_secure_spec.rb
  • qa/qa/specs/features/browser_ui/4_verify/runner/register_runner_spec.rb

使用例：

docker run \
  --detach \
  --hostname interface_ip_address \
  --publish 80:80 \
  --name gitlab \
  --restart always \
  --volume ~/ee_volume/config:/etc/gitlab \
  --volume ~/ee_volume/logs:/var/log/gitlab \
  --volume ~/ee_volume/data:/var/opt/gitlab \
  --shm-size 256m \
  gitlab/gitlab-ee:latest

ここで、interface_ip_address はあなたのローカルネットワークのインターフェースIPで、ifconfig コマンドで見つけることができます。インスタンスアドレスをlocalhost としてGDKを実行する場合も同様です。

Geoテスト

Geoエンドツーエンドテストは、Geo GDKセットアップに対してローカルで実行することも、DockerコンテナでスピンアップしたGeo上で実行することもできます。

Geo GDK の使用法

GDKのGeoプライマリインスタンスとGeoセカンダリインスタンスの両方が稼働している状態で、qa/ ディレクトリ から実行します：

WEBDRIVER_HEADLESS=false bundle exec bin/qa QA::EE::Scenario::Test::Geo --primary-address http://localhost:3001 --secondary-address http://localhost:3002 --without-setup

DockerでのGeoの使用

GitLab-QA Orchestratorを使って2つのGitLabコンテナをオーケストレーションし、Geoセットアップとして設定することができます。

GeoにはEEライセンスが必要です。ブラウザでGeoサイトにアクセスするには、リバースプロキシサーバ（NGINXなど）が必要です。

  1. EE ライセンスのエクスポート

    export EE_LICENSE=$(cat <path/to/your/gitlab_license>)

  2. オプションGitLabイメージのプル

    Docker イメージのプルはTest::Integration::Geo オーケストレーションシナリオ の一部なので、このステップはオプションです。しかし、最初にイメージをプルした方がダウンロードの進捗を監視しやすくなります。シナリオでは、イメージが最新であることを確認した後にこのステップをスキップします。

    # For the most recent nightly image
docker pull gitlab/gitlab-ee:nightly
   
# For a specific release
docker pull gitlab/gitlab-ee:13.0.10-ee.0
   
# For a specific image
docker pull registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:examplesha123456789

  3. Test::Integration::Geo オーケストレーションシナリオ を--no-teardown オプション付きで実行し、GitLab コンテナを構築し、Geo セットアップを設定し、Geo エンドツーエンドテストを実行します。Geo のセットアップが完了した後のテストの実行は任意です。テストを停止した後もコンテナは実行され続けます。

    # Using the most recent nightly image
gitlab-qa Test::Integration::Geo EE --no-teardown
   
# Using a specific GitLab release
gitlab-qa Test::Integration::Geo EE:13.0.10-ee.0 --no-teardown
   
# Using a full image address
GITLAB_QA_ACCESS_TOKEN=your-token-here gitlab-qa Test::Integration::Geo registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:examplesha123456789 --no-teardown

    --no-tests オプションを使用してコンテナのみを構築し、GDK からEE::Scenario::Test::Geo シナリオ を実行してセットアップを完了し、テストを実行することができます。しかし、GDKとコンテナが異なるGitLabバージョンをベースにしている場合、設定にイシューが発生する可能性があります。--no-teardown オプションでは、GitLab-QAはGeoセットアップの設定に使用するGitLabコンテナとGitLab QAコンテナに同じGitLabバージョンを使用します。

  4. ブラウザでGeoサイトを訪問するには、コンテナ内で使用されているホスト名へのリクエストをプロキシします。この例では、NGINX をリバースプロキシサーバとして使用しています。

    マシンの/etc/hosts ファイルで、ホスト名を内部 IP にマッピングします：

    127.0.0.1 gitlab-primary.geo gitlab-secondary.geo

    割り当てられたポートに注意してください：

    $ docker port gitlab-primary
   
80/tcp -> 0.0.0.0:32768
   
$ docker port gitlab-secondary
   
80/tcp -> 0.0.0.0:32769

    nginx.conf （通常Macの/usr/local/etc/nginx ）に割り当てられたポートでリバースプロキシサーバーを設定します：

    server {
  server_name gitlab-primary.geo;
  location / {
    proxy_pass http://localhost:32768; # Change port to your assigned port
    proxy_set_header Host gitlab-primary.geo;
  }
}
   
server {
  server_name gitlab-secondary.geo;
  location / {
    proxy_pass http://localhost:32769; # Change port to your assigned port
    proxy_set_header Host gitlab-secondary.geo;
  }
}

    リバースプロキシサーバーを起動するか、リロードします：

    sudo nginx
# or
sudo nginx -s reload

  5. ローカル GDK からエンドツーエンドテストを実行するには、gitlab/qa/ ディレクトリ からEE::Scenario::Test::Geo シナリオ を実行します。Geo 設定ステップをスキップするには、--without-setup をインクルードしてください。

    QA_LOG_LEVEL=debug GITLAB_QA_ACCESS_TOKEN=[add token here] GITLAB_QA_ADMIN_ACCESS_TOKEN=[add token here] bundle exec bin/qa QA::EE::Scenario::Test::Geo \
--primary-address http://gitlab-primary.geo \
--secondary-address http://gitlab-secondary.geo \
--without-setup

    コンテナを最初に設定する必要がある場合（例えば、前のステップで--no-tests オプションを使用した場合）、以下に示すようにQA::EE::Scenario::Test::Geo scenario を実行し、最初に Geo 設定ステップを行い、その後 Geo エンドツーエンドテストを実行します。シェルセッションでEE_LICENSE が（まだ）定義されていることを確認してください。

    QA_LOG_LEVEL=debug bundle exec bin/qa QA::EE::Scenario::Test::Geo \
--primary-address http://gitlab-primary.geo \
--primary-name gitlab-primary \
--secondary-address http://gitlab-secondary.geo \
--secondary-name gitlab-secondary

  6. コンテナの停止と削除

    docker stop gitlab-primary gitlab-secondary
docker rm gitlab-primary gitlab-secondary

備考

  • 以下の手順に従って、パイプラインからフルイメージアドレスを見つけることができます。フルイメージアドレスを指定すると、GITLAB_QA_ACCESS_TOKEN 変数を設定するよう求められることがあります。
  • GEO_MAX_FILE_REPLICATION_TIME とGEO_MAX_DB_REPLICATION_TIME を設定すると、レプリケーションの待機時間を長くすることができます。デフォルトは120秒です。
  • テスト中の時間を節約するには、プライマリノードで API アクセスを持つパーソナルアクセストークンを作成し、その値をGITLAB_QA_ACCESS_TOKEN およびGITLAB_QA_ADMIN_ACCESS_TOKEN として渡します。

LDAP テスト

:ldap_tls と:ldap_no_tls meta のタグが付けられたテストは、LDAP 経由でサインインするオーケストレーションされたテストです。

これらのテストは、OpenLDAPのインスタンスを実行する Docker コンテナ(osixia/openldap) をスピンアップします。コンテナはGitLab-QA リポジトリにチェックインされたフィクスチャを使って、管理者グループを含むユーザーやグループなどのベースデータを作成します。tanuki ユーザー を含むすべてのユーザーのパスワードはpasswordです。

GitLab インスタンスも、LDAP セットアップのドキュメントに基づいて Docker コンテナ内に作成されます。

:ldap_tls とタグ付けされたテストは、GitLab-QAリポジトリにチェックインされた証明書を使ってGitLab上でTLSを有効にします。

証明書はこのコマンドを使って OpenSSL で生成されました：

openssl req -x509 -newkey rsa:4096 -keyout gitlab.test.key -out gitlab.test.crt -days 3650 -nodes -subj "/C=US/ST=CA/L=San Francisco/O=GitLab/OU=Org/CN=gitlab.test"

OpenLDAP コンテナは、自動生成された TLS 証明書も使用します。

TLS を有効にした LDAP テストの実行

ローカルで TLS を有効にして LDAP テストを実行するには、以下の手順に従います：

  1. /etc/hosts ファイルに以下のエントリを記述します：

    127.0.0.1 gitlab.test

    そして、https://gitlab.test 上の Docker コンテナで GitLab に対してテストを実行することができます。GitLab-QAリポジトリにチェックインされたTLS証明書は、このドメイン用に設定されています。

  2. TLS を有効にして OpenLDAP コンテナを実行します。gitlab-qa/fixtures/ldap ディレクトリへのパスを、あなたの内部チェックアウト・パスに変更します：

    docker network create test && docker run --name ldap-server --net test --hostname ldap-server.test --volume /path/to/gitlab-qa/fixtures/ldap:/container/service/slapd/assets/config/bootstrap/ldif/custom:Z --env LDAP_TLS_CRT_FILENAME="ldap-server.test.crt" --env LDAP_TLS_KEY_FILENAME="ldap-server.test.key" --env LDAP_TLS_ENFORCE="true" --env LDAP_TLS_VERIFY_CLIENT="never" osixia/openldap:latest --copy-service

  3. GitLab コンテナを TLS を有効にして実行。gitlab-qa/tls_certificates/gitlab ディレクトリへのパスをローカルのチェックアウトパスに変更します：

    sudo docker run \
   --hostname gitlab.test \
   --net test \
   --publish 443:443 --publish 80:80 --publish 22:22 \
   --name gitlab \
   --volume /path/to/gitlab-qa/tls_certificates/gitlab:/etc/gitlab/ssl \
   --env GITLAB_OMNIBUS_CONFIG="gitlab_rails['ldap_enabled'] = true; gitlab_rails['ldap_servers'] = {\"main\"=>{\"label\"=>\"LDAP\", \"host\"=>\"ldap-server.test\", \"port\"=>636, \"uid\"=>\"uid\", \"bind_dn\"=>\"cn=admin,dc=example,dc=org\", \"password\"=>\"admin\", \"encryption\"=>\"simple_tls\", \"verify_certificates\"=>false, \"base\"=>\"dc=example,dc=org\", \"user_filter\"=>\"\", \"group_base\"=>\"ou=Global Groups,dc=example,dc=org\", \"admin_group\"=>\"AdminGroup\", \"external_groups\"=>\"\", \"sync_ssh_keys\"=>false}}; letsencrypt['enable'] = false; external_url 'https://gitlab.test'; gitlab_rails['ldap_sync_worker_cron'] = '* * * * *'; gitlab_rails['ldap_group_sync_worker_cron'] = '* * * * *'; " \
   gitlab/gitlab-ee:latest

  4. gitlab/qa ディレクトリから LDAP テストを実行します：

    GITLAB_LDAP_USERNAME="tanuki" GITLAB_LDAP_PASSWORD="password" QA_LOG_LEVEL=debug WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All https://gitlab.test qa/specs/features/browser_ui/1_manage/login/log_into_gitlab_via_ldap_spec.rb

TLSを無効にしたLDAPテストの実行

TLSを無効にしてローカルでLDAPテストを実行するには、以下の手順に従います：

  1. OpenLDAP コンテナを TLS 無効で起動します。gitlab-qa/fixtures/ldap ディレクトリへのパスをローカルのチェックアウトパスに変更します：

    docker network create test && docker run --net test --publish 389:389 --publish 636:636 --name ldap-server --hostname ldap-server.test --volume /path/to/gitlab-qa/fixtures/ldap:/container/service/slapd/assets/config/bootstrap/ldif/custom:Z --env LDAP_TLS="false" osixia/openldap:latest --copy-service

  2. GitLab コンテナを実行します：

    sudo docker run \
  --hostname localhost \
  --net test \
  --publish 443:443 --publish 80:80 --publish 22:22 \
  --name gitlab \
  --env GITLAB_OMNIBUS_CONFIG="gitlab_rails['ldap_enabled'] = true; gitlab_rails['ldap_servers'] = {\"main\"=>{\"label\"=>\"LDAP\", \"host\"=>\"ldap-server.test\", \"port\"=>389, \"uid\"=>\"uid\", \"bind_dn\"=>\"cn=admin,dc=example,dc=org\", \"password\"=>\"admin\", \"encryption\"=>\"plain\", \"verify_certificates\"=>false, \"base\"=>\"dc=example,dc=org\", \"user_filter\"=>\"\", \"group_base\"=>\"ou=Global Groups,dc=example,dc=org\", \"admin_group\"=>\"AdminGroup\", \"external_groups\"=>\"\", \"sync_ssh_keys\"=>false}}; gitlab_rails['ldap_sync_worker_cron'] = '* * * * *'; gitlab_rails['ldap_group_sync_worker_cron'] = '* * * * *'; " \
gitlab/gitlab-ee:latest

  3. gitlab/qa ディレクトリから LDAP テストを実行します：

    GITLAB_LDAP_USERNAME="tanuki" GITLAB_LDAP_PASSWORD="password" QA_LOG_LEVEL=debug WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All http://localhost qa/specs/features/browser_ui/1_manage/login/log_into_gitlab_via_ldap_spec.rb

SMTPテスト

:smtp メタタグが付けられたテストは、電子メール通知がユーザに受信されることを保証するオーケストレーショ ンされたテストです。

これらのテストには、SMTP を有効にして SMTP サーバーMailHogとインテグレーションした GitLab インスタンスが必要です。

これらのテストを GDK に対してローカルで実行するには、次のようにします：

  1. 以下の設定をgitlab.yml ファイルに追加してください：

    smtp:
  enabled: true
  address: "mailhog.test"
  port: 1025

  2. DockerコンテナでMailHogを起動します：

    docker network create test && docker run \
  --network test \
  --hostname mailhog.test \
  --name mailhog \
  --publish 1025:1025 \
  --publish 8025:8025 \
  mailhog/mailhog:v1.0.0

  3. gitlab/qa ディレクトリからテストを実行します：

    QA_LOG_LEVEL=debug WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All http://localhost:3000 qa/specs/features/browser_ui/2_plan/email/trigger_email_notification_spec.rb -- --tag orchestrated

gitlab-qa gem を使ってこれらのテストを実行する方法については、GitLab QA ドキュメントを参照してください。

モバイルスイートのガイド

モバイルテストとは

:mobile とタグ付けされたテストは、クラウドエミュレータ/シミュレータサービスを使用して、指定されたモバイルデバイスに対して実行することができます。

Sauce Labsでモバイルテストを実行する方法

Sauce Labsのテストログは認証情報を公開するため、ステージングのような環境に対して直接実行することは推奨されません。したがって、トンネルを使用するのがベストプラクティスであり、デフォルトです。

トンネルのインストール手順については、Sauce Connect Proxy Installationを参照してください。トンネルを開始するには、上記のインストールに従った後、Sauce Labs > Tunnelsにあるrunコマンドをコピーし（1Passwordにある認証情報でSauce Labsにログインする必要があります）、ターミナルで実行します。

note
テストを高速化し、フラックを減らすために、GITLAB_QA_ACCESS_TOKEN を使用することを強くお勧めします。

QA_REMOTE_MOBILE_DEVICE_NAME には、「Emulators/simulators and the latest versions of Android or iOS」の「Supported browsers and devices」に記載されている任意のデバイス名を指定できます。QA_BROWSER は、iOS デバイスの場合はsafari に、Android デバイスの場合はchrome に設定する必要があります。

  1. トンネルが実行されているローカル・インスタンスに対してテストするには、gitlab/qa を実行します：
$ QA_BROWSER="safari" \
  QA_REMOTE_MOBILE_DEVICE_NAME="iPhone 12 Simulator" \
  QA_REMOTE_GRID="ondemand.saucelabs.com:80" \
  QA_REMOTE_GRID_USERNAME="gitlab-sl" \
  QA_REMOTE_GRID_ACCESS_KEY="<found in Sauce Lab account>" \
  GITLAB_QA_ACCESS_TOKEN="<token>" \
  bundle exec bin/qa Test::Instance::All http://<local_ip>:3000 -- <relative_spec_path>

結果は、Sauce Labsにログインしている間、AUTOMATED > Test Resultsでリアルタイムで見ることができます。

既存のテストをモバイルスイートに追加する方法

:mobile タグを追加したときにテストが失敗する主な理由は、デスクトップとモバイルのレイアウトにおけるナビゲーションの違いです。

既存のメソッドを変更したり、新しいメソッドを作成したりする必要がある場合は、qa/qa/mobile/page/ で新しいモバイルページオブジェクトを作成し、元のページオブジェクトの先頭に追加します：

prepend Mobile::Page::NewPageObject if Runtime::Env.mobile_layout?

たとえば、モバイルテストを実行するとき、既存のメソッドを変更します：

新しいモバイルページオブジェクト：

module QA
  module Mobile
    module Page
      module Project
        module Show
          extend QA::Page::PageConcern

          def self.prepended(base)
            super

            base.class_eval do
              prepend QA::Mobile::Page::Main::Menu

              view 'app/assets/javascripts/nav/components/top_nav_new_dropdown.vue' do
                element :new_issue_mobile_button
              end
            end
          end

          def go_to_new_issue
            open_mobile_new_dropdown

            click_element(:new_issue_mobile_button)
          end
        end
      end
    end
  end
end

モバイルレイアウトがある場合、新しいモバイルの前にオリジナルのページオブジェクトを追加します：

module QA
  module Page
    module Project
      class Show < Page::Base
        prepend Mobile::Page::Project::Show if Runtime::Env.mobile_layout?

        view 'app/views/layouts/header/_new_dropdown.html.haml' do
          element :new_menu_toggle
        end

        view 'app/helpers/nav/new_dropdown_helper.rb' do
          element :new_issue_link
        end

        def go_to_new_issue
          click_element(:new_menu_toggle)
          click_element(:new_issue_link)
        end
      end
    end
  end
end

スマホレイアウトでモバイルテストを実行する場合、remote_mobile_device_name とmobile_layout の両方がtrue になりますが、タブレットレイアウトをremote_mobile_device_name 使用する場合は、 remote_mobile_device_nameのみがremote_mobile_device_name 真に remote_mobile_device_nameなります。remote_mobile_device_name これは、タブレットと電話の両方が左ナビを閉じているように、電話レイアウトはデフォルトでより多くのメニューを閉じているためですが、電話レイアウトとは異なり、タブレットはモバイルのものではなく、通常のトップナビゲーションバーを持っています。そのため、編集中のナビゲーションをタブレットレイアウトでも使用する必要がある場合、 remote_mobile_device_name mobile_layout? の代わりに使用してください。

ライブ環境におけるカナリアコンポーネントと非カナリアコンポーネントの比較

canary (staging-canary またはcanary) またはnon-canary (staging またはproduction) 環境をテスト全体のターゲットにするには、QA_COOKIES ENV 変数を使用します。

ローカルでは、bin/qaの呼び出しの前にENV変数を追加することになります。canary バージョンの環境をターゲットにするには、次のようにします：

QA_COOKIES="gitlab_canary=true" WEBDRIVER_HEADLESS=false bin/qa Test::Instance::Staging <YOUR SPECIFIC TAGS OR TESTS>

あるいは、non-canary バージョンがターゲットになるように、クッキーをfalse に設定することもできます。

また、現在のセッションのクッキーをエクスポートして、毎回クッキーをプリペンドするのを避けることもできます：

export QA_COOKIES="gitlab_canary=true"

特定のテスト内で、staging やproduction などのライブ環境内のcanary またはnon-canary ノードのいずれかをターゲットにすることができます。

たとえば、2つの環境を行ったり来たりするには、target_canary ：

it 'tests toggling between canary and non-canary nodes' do
  Runtime::Browser.visit(:gitlab, Page::Main::Login)

  # After starting the browser session, use the target_canary method ...

  Runtime::Browser::Session.target_canary(true)
  Flow::Login.sign_in

  verify_session_on_canary(true)

  Runtime::Browser::Session.target_canary(false)

  # Refresh the page ...

  verify_session_on_canary(false)

  # Log out and clean up ...
end

def verify_session_on_canary(enable_canary)
  Page::Main::Menu.perform do |menu|
    aggregate_failures 'testing session log in' do
      expect(menu.canary?).to be(enable_canary)
    end
  end
end

GitLab がcanary やnon-canary のノードにセッションを適切にリダイレクトしているかどうかは、menu.canary? メソッドで確認できます。

上記の仕様は冗長ですが、これは実装の背後にある考え方が明確であることを保証するために特別に書かれたものです。エンドツーエンドのテストの書き方については、 Beginner’s Guideに詳しく書かれているので、それに従うことを推奨します。

OpenID Connect(OIDC) および OAuth プロバイダとしての GitLab のテスト

login_via_oauth_and_oidc_with_gitlab_as_idp_spec を内部マシンで実行します：

  1. GDK がgdk.test:3000 のような非ローカルホストのアドレスで動作するように設定されていることを確認してください。
  2. ループバックインターフェースを172.16.123.1に設定します。
  3. Docker DesktopまたはRancher Desktopが起動していることを確認します。
  4. gitlab-oidc-consumer.bridge とgitlab-oauth-consumer.bridge の/etc/hosts ファイルに127.0.0.1を指すエントリを追加します。

  5. qa ディレクトリから、以下のコマンドを実行します。使用する GitLab イメージを設定するには、変数を更新しますRELEASE 。 RELEASE例えば、RELEASE 最新の EE イメージを RELEASE使用するには、gitlab/gitlab-ee:latest にRELEASE 設定 RELEASEします：

    bundle install
   
RELEASE_REGISTRY_URL='registry.gitlab.com' RELEASE_REGISTRY_USERNAME='<your_gitlab_username>' RELEASE_REGISTRY_PASSWORD='<your_gitlab_personal_access_token>' RELEASE='registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:c0ae46db6b31ea231b2de88961cd687acf634179' GITLAB_QA_ADMIN_ACCESS_TOKEN="<your_gdk_admin_personal_access_token>" QA_DEBUG=true CHROME_HEADLESS=false bundle exec bin/qa Test::Instance::All http://gdk.test:3000 qa/specs/features/browser_ui/1_manage/login/login_via_oauth_and_oidc_with_gitlab_as_idp_spec.rb