运行需要特殊设置的测试

Jenkins 测试

jenkins_build_status_spec 会在 Docker 容器中启动一个 Jenkins 实例，并预装 Jenkins GitLab 插件。由于许可证限制，我们无法分发此镜像。 要构建兼容 QA 的镜像，请访问 第三方镜像项目，其中可找到第三方 Dockerfile。 该项目还提供了在 CI 中自动分叉和构建镜像的说明。

此外，还需要一些额外的环境变量来指定分叉仓库的位置：

• QA_THIRD_PARTY_DOCKER_REGISTRY（托管仓库/镜像的容器注册表地址，例如 registry.gitlab.com）
• QA_THIRD_PARTY_DOCKER_REPOSITORY（托管镜像的基础仓库路径，例如 registry.gitlab.com/<项目路径>）
• QA_THIRD_PARTY_DOCKER_USER（有权访问此仓库容器注册表的用户名）
• QA_THIRD_PARTY_DOCKER_PASSWORD（用于用户认证的密码/令牌）

测试会使用运行测试所用的 GitLab 实例 URL，配置 Jenkins 中的 GitLab 插件。GitLab 实例与 Jenkins 之间需要双向网络连接，因此 GitLab 也可以在 Docker 容器中启动。

基于 nightly 镜像启动 GitLab 的 Docker 容器：

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

从 /qa 目录运行测试：

export QA_THIRD_PARTY_DOCKER_REGISTRY=<注册表地址>
export QA_THIRD_PARTY_DOCKER_REPOSITORY=<仓库地址>
export QA_THIRD_PARTY_DOCKER_USER=<拥有注册表访问权限的用户>
export QA_THIRD_PARTY_DOCKER_PASSWORD=<用户密码>
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 集群 (Praefect) 测试

标记为 :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 操作是通过 UI 中显示的克隆 URL 执行的。它使用为 GitLab 实例配置的主机名，此处与 Docker 容器名称和网络 gitlab-gitaly-cluster.test 匹配。运行测试前需要配置您的计算机通过该地址访问容器。一种选择是 使用 Caddy 服务器（如针对 GDK 运行测试所述）。

另一种选择是使用 NGINX。

无论哪种情况，都必须配置您的机器将 gitlab-gitaly-cluster.test 解析为适当的 IP 地址：

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

然后安装 NGINX：

# 在 macOS 上
brew install nginx

# 在 Debian/Ubuntu 上
apt install nginx

# 在 Fedora 上
yum install nginx

最后，配置 NGINX 将 gitlab-gitaly-cluster.test 的请求转发到 GitLab 实例：

# 在 Debian/Ubuntu 上，位于 /etc/nginx/sites-enabled/gitlab-cluster
# 在 macOS 上，位于 /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 使配置生效。例如：

# 在 Debian/Ubuntu 上
sudo systemctl restart nginx

# 在 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 实例时，Docker run 命令中的 --hostname 参数应指定特定接口 IP 地址或运行器容器可访问的非回环主机名。将 GitLab 主机名设为 localhost（或 127.0.0.1）将无法工作（除非 GitLab Runner 是以 Docker 网络为 host 创建的）。

需要运行器的测试示例：

• 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

在 qa/ 目录 中运行，确保 Geo 主节点和 Geo 从节点都在运行：

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 编排器 来编排两个 GitLab 容器并将它们配置为 Geo 设置。

Geo 需要 EE 许可证。要在浏览器中访问 Geo 网站，您需要一个反向代理服务器（例如 NGINX）。

1. 导出您的 EE 许可证

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

2. 可选：拉取 GitLab 镜像

   此步骤是可选的，因为拉取 Docker 镜像是 Test::Integration::Geo 编排场景 的一部分。但如果先拉取镜像，更容易监控下载进度，且场景在检查镜像最新后会跳过此步骤。

   # 对于最新的 nightly 镜像
   docker pull gitlab/gitlab-ee:nightly
   
   # 对于特定版本
   docker pull gitlab/gitlab-ee:13.0.10-ee.0
   
   # 对于特定镜像
   docker pull registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:examplesha123456789

3. 使用 --no-teardown 选项运行 Test::Integration::Geo 编排场景，构建 GitLab 容器、配置 Geo 设置并运行 Geo 端到端测试。在 Geo 设置完成后运行测试是可选的；容器在您停止测试后仍会保持运行。

   # 使用最新的 nightly 镜像
   gitlab-qa Test::Integration::Geo EE --no-teardown
   
   # 使用特定 GitLab 版本
   gitlab-qa Test::Integration::Geo EE:13.0.10-ee.0 --no-teardown
   
   # 使用完整镜像地址
   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 对 GitLab 容器和用于配置 Geo 的 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; # 更改为您分配的端口
       proxy_set_header Host gitlab-primary.geo;
     }
   }
   
   server {
     server_name gitlab-secondary.geo;
     location / {
       proxy_pass http://localhost:32769; # 更改为您分配的端口
       proxy_set_header Host gitlab-secondary.geo;
     }
   }

   启动或重新加载反向代理服务器：

   sudo nginx
   # 或
   sudo nginx -s reload

5. 要从本地 GDK 运行端到端测试，请从 gitlab/qa/ 目录 运行 EE::Scenario::Test::Geo 场景。包含 --without-setup 以跳过 Geo 配置步骤。

   QA_LOG_LEVEL=debug GITLAB_QA_ACCESS_TOKEN=[在此添加令牌] GITLAB_QA_ADMIN_ACCESS_TOKEN=[在此添加令牌] 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 场景，先执行 Geo 配置步骤，然后运行 Geo 端到端测试。确保 EE_LICENSE 在您的 shell 会话中（仍然）已定义。

   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 秒。
• 为节省测试时间，请在 Geo 主节点上创建一个具有 API 访问权限的个人访问令牌，并将其值作为 GITLAB_QA_ACCESS_TOKEN 和 GITLAB_QA_ADMIN_ACCESS_TOKEN 传入。

组 SAML 测试

标记有 :group_saml 元标签的测试是编排测试，用户通过 SAML SSO 访问组。

这些测试依赖于一个 SAML IDP Docker 容器（jamedjo/test-SAML-idp）。测试会自行启动该容器。

要在您的计算机上针对 GDK 运行这些测试：

1. 将以下设置添加到您的 gitlab.yml 文件中：

   omniauth:
     enabled: true
     providers:
       - { name: 'group_saml' }

2. 从 gitlab/qa 目录运行组 SAML 测试：

   QA_DEBUG=true CHROME_HEADLESS=false bundle exec bin/qa Test::Instance::All http://localhost:3000 qa/specs/features/ee/browser_ui/1_manage/group/group_saml_enforced_sso_spec.rb -- --tag orchestrated

有关如何使用 gitlab-qa gem 运行这些测试的说明，请参考 GitLab QA 文档。

实例 SAML 测试

标记有 :instance_saml 元标签的测试是编排测试，实例级登录使用 SAML SSO。

这些测试需要配置并运行一个 SAML IDP Docker 容器（jamedjo/test-SAML-idp）。

要在您的计算机上针对 GDK 运行这些测试：

1. 将以下设置添加到您的 gitlab.yml 文件中：

   omniauth:
     enabled: true
     allow_single_sign_on: ["saml"]
     block_auto_created_users: false
     auto_link_saml_user: true
     providers:
       - { name: 'saml',
         args: {
         assertion_consumer_service_url: 'http://gdk.test:3000/users/auth/saml/callback',
         idp_cert_fingerprint: '11:9b:9e:02:79:59:cd:b7:c6:62:cf:d0:75:d9:e2:ef:38:4e:44:5f',
         idp_sso_target_url: 'https://gdk.test:8443/simplesaml/saml2/idp/SSOService.php',
         issuer: 'http://gdk.test:3000',
         name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'
       } }

2. 启动 SAML IDP Docker 容器：

   docker run --name=group_saml_qa_idp -p 8080:8080 -p 8443:8443 \
   -e SIMPLESAMLPHP_SP_ENTITY_ID=http://localhost:3000 \
   -e SIMPLESAMLPHP_SP_ASSERTION_CONSUMER_SERVICE=http://localhost:3000/users/auth/saml/callback \
   -d jamedjo/test-saml-idp

3. 从 gitlab/qa 目录运行测试：

   QA_DEBUG=true CHROME_HEADLESS=false bundle exec bin/qa Test::Instance::All http://localhost:3000 qa/specs/features/browser_ui/1_manage/login/login_via_instance_wide_saml_sso_spec.rb -- --tag orchestrated

有关如何使用 gitlab-qa gem 运行这些测试的说明，请参考 GitLab QA 文档。

LDAP 测试

标记有 :ldap_tls 和 :ldap_no_tls 元标签的测试是编排测试，登录通过 LDAP 进行。

这些测试会启动一个运行 OpenLDAP 实例的 Docker 容器（osixia/openldap）。 该容器使用 签入 GitLab-QA 仓库的 fixture 创建基础数据，包括用户和组（包括管理员组）。所有用户（包括 tanuki 用户）的密码均为 password。

还会根据我们的 LDAP 设置 文档，在 Docker 容器中创建一个 GitLab 实例。

标记为 :ldap_tls 的测试会在 GitLab 上启用 TLS，使用 签入 GitLab-QA 仓库的证书。

该证书是使用 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

   您随后可以针对 Docker 容器中的 GitLab 在 https://gitlab.test 上运行测试。该域名的 TLS 证书 已签入 GitLab-QA 仓库。

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. 启用 TLS 运行 GitLab 容器。将路径更改为您本地的 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. 禁用 TLS 运行 OpenLDAP 容器。将路径更改为您本地的 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 文档。

在生产环境中定位 Canary 与非 Canary 组件

使用 QA_COOKIES 环境变量让整个测试定位到 canary（staging-canary 或 canary）或 non-canary（staging 或 production）环境。

在本地，这意味着在调用 bin/qa 时预先添加该环境变量。要定位该环境的 canary 版本：

QA_COOKIES="gitlab_canary=true" WEBDRIVER_HEADLESS=false bin/qa Test::Instance::Staging <您的特定标签或测试>

或者，您可以将 cookie 设置为 false 以确保定位到 non-canary 版本。

您也可以导出 cookie 以避免每次预先添加：

export QA_COOKIES="gitlab_canary=true"

在运行中的测试中更新 cookie

在特定测试中，您可以在 staging 和 production 等生产环境中定位 canary 或 non-canary 节点。

例如，要在两个环境之间切换，您可以使用 target_canary 方法：

it '测试在 canary 和 non-canary 节点之间切换' do
  Runtime::Browser.visit(:gitlab, Page::Main::Login)

  # 启动浏览器会话后，使用 target_canary 方法 ...

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

  verify_session_on_canary(true)

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

  # 刷新页面 ...

  verify_session_on_canary(false)

  # 登出并清理 ...
end

def verify_session_on_canary(enable_canary)
  Page::Main::Menu.perform do |menu|
    aggregate_failures '测试会话登录' do
      expect(menu.canary?).to be(enable_canary)
    end
  end
end

您可以使用 menu.canary? 方法验证 GitLab 是否正确将您的会话重定向到 canary 或 non-canary 节点。

上述示例写得详细，专门这样写是为了确保实现背后的想法清晰。我们建议遵循我们 端到端测试初学者指南 中详述的最佳实践。

GitLab 作为 OpenID Connect (OIDC) 和 OAuth 提供者的测试

要在您的本地机器上运行 login_via_oauth_and_oidc_with_gitlab_as_idp_spec：

1. 确保您的 GDK 运行在非 localhost 地址上，例如 gdk.test:3000。

2. 配置环回接口为 172.16.123.1。

3. 确保 Docker Desktop 或 Rancher Desktop 正在运行。

4. 在您的 /etc/hosts 文件中添加 gitlab-oidc-consumer.bridge 和 gitlab-oauth-consumer.bridge 条目，指向 127.0.0.1。

5. 从 qa 目录运行以下命令。要设置您要使用的 GitLab 镜像，请更新 RELEASE 变量。例如，要使用最新的 EE 镜像，将 RELEASE 设置为 gitlab/gitlab-ee:latest：

   bundle install
   
   RELEASE_REGISTRY_URL='registry.gitlab.com' RELEASE_REGISTRY_USERNAME='<您的_gitlab用户名>' RELEASE_REGISTRY_PASSWORD='<您的_gitlab个人访问令牌>' RELEASE='registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:c0ae46db6b31ea231b2de88961cd687acf634179' GITLAB_QA_ADMIN_ACCESS_TOKEN="<您的_gdk管理员个人访问令牌>" 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

产品分析 (Product Analytics) 测试

产品分析端到端测试需要运行产品分析服务并将其连接到您的 GDK。

要运行产品分析服务，可以使用 devkit。设置说明和连接到 GDK 的说明可在 devkit 项目的 README.md 中找到。

此外，GDK 上还需要以下设置：

• 为产品分析配置设置环境变量。以下变量是用于本地运行 devkit的默认值。

  export PA_CONFIGURATOR_URL=http://test:test@localhost:4567
  export PA_COLLECTOR_HOST=http://localhost:9091
  export PA_CUBE_API_URL=http://localhost:4000
  export PA_CUBE_API_KEY=thisisnotarealkey43ff15165ce01e4ff47d75092e3b25b2c0b20dc27f6cd5a8aed7b7bd855df88c9e0748d7afd37adda6d981c16177b086acf496bbdc62dbb

• 应用 Ultimate 许可证。

  • 如何申请许可证。
  • 如何使用许可证文件或密钥激活 GitLab EE。

• 模拟 SaaS 已启用。说明可 在此处找到。

一旦产品分析服务运行并连接到您的 GDK，就可以使用以下命令执行测试：

bundle exec rspec qa/specs/features/ee/browser_ui/8_monitor/product_analytics/onboarding_spec.rb

需要全局服务器钩子 (global server hook) 的测试

tag_revision_trigger_prereceive_hook_spec 需要在目标测试环境中预配置全局服务器钩子。当在本地 GDK 上运行此测试时，服务器钩子需要通过以下方式配置：

# 从 gdk 目录
mkdir -p gitaly-custom-hooks/pre-receive.d
cp gitlab/qa/gdk/pre-receive gitaly-custom-hooks/pre-receive.d
chmod +x gitaly-custom-hooks/pre-receive.d/pre-receive

有关全局服务器钩子的更多信息，请参阅 服务器钩子文档。