특수 설정이 필요한 테스트 실행

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 엔진에서 사용하는 메모리를 늘려보세요.

Gitaly 클러스터 테스트

:gitaly_ha 태그가 붙은 테스트는 구성 및 시작된 Docker 컨테이너 세트에 대해 실행할 수 있는 조정된 테스트입니다 the Test::Integration::GitalyCluster GitLab QA 시나리오.

위에서 언급한 시나리오에 대한 문서에 설명된 것처럼 다음 명령어가 테스트를 실행합니다:

gitlab-qa Test::Integration::GitalyCluster EE

그러나, 테스트가 실행된 후 컨테이너가 제거됩니다. 추가 테스트를 수행하려는 경우, 예를 들어 디버거를 통해 특정 테스트를 실행하고자 할 경우 the --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. 테스트를 실행하기 전에 이 주소를 통해 컨테이너에 접근할 수 있도록 컴퓨터를 구성해야 합니다. 한 가지 옵션은 GDK에 대한 테스트 실행을 위해 설명된 Caddy 서버 사용입니다.

또 다른 옵션은 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

러너가 필요한 테스트

러너를 사용하는 테스트를 오류 없이 실행하려면, GitLab Docker 인스턴스를 생성할 때 Docker run 명령어의 --hostname 매개변수에 특정 인터페이스 IP 주소 또는 러너 컨테이너에서 접근할 수 있는 비루프백 호스트 이름을 지정해야 합니다. localhost(또는 127.0.0.1)를 GitLab 호스트 이름으로 사용하는 것은 작동하지 않습니다(단, 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는 ifconfig 명령어로 찾을 수 있는 로컬 네트워크의 인터페이스 IP입니다.

이와 동일하게 GDK가 인스턴스 주소를 localhost로 실행되도록 설정할 수도 있습니다.

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 컨테이너를 오케스트레이션하고 Geo 설정으로 구성하려면 GitLab-QA 오케스트레이터를 사용할 수 있습니다.

Geo는 EE 라이센스가 필요합니다. 브라우저에서 Geo 사이트를 방문하려면 리버스 프록시 서버(예: NGINX)가 필요합니다.

  1. EE 라이센스 내보내기

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

  2. 선택 사항. GitLab 이미지 풀

    이 단계는 선택 사항입니다. Docker 이미지를 풀하는 것은 Test::Integration::Geo 오케스트레이션 시나리오의 일부입니다. 그러나 이미지를 처음부터 풀면 다운로드 진행 상황을 모니터링하기가 더 쉽고, 시나리오는 이미지가 최신인지 확인한 후 이 단계를 건너뜁니다.

    # 가장 최근의 야간 이미지
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 설정이 완료된 후 테스트를 실행하는 것은 선택 사항입니다. 테스트를 중지한 후에도 컨테이너는 계속 실행됩니다.

    # 가장 최근의 야간 이미지 사용
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

    컨테이너만 생성하고 EE::Scenario::Test::Geo 시나리오를 실행하여 설정을 완료하고 테스트를 실행할 수 있습니다. 그러나 GDK와 컨테이너가 서로 다른 GitLab 버전에 기반하고 있을 경우 구성 문제 발생 가능성이 있습니다. --no-teardown옵션을 사용하면 GitLab-QA는 GitLab 컨테이너와 Geo 설정을 구성하는 데 사용되는 GitLab QA 컨테이너에 동일한 GitLab 버전을 사용합니다.

  4. 브라우저에서 Geo 사이트에 방문하기 위해 컨테이너 내부에서 사용되는 호스트 이름으로 요청을 프록시합니다. 이 예에서는 NGINX가 리버스 프록시 서버로 사용됩니다.

    호스트 이름을 로컬 IP에 매핑하여 /etc/hosts 파일에 다음과 같이 설정합니다:

    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에서 엔드 투 엔드 테스트를 실행하려면 EE::Scenario::Test::Geo 시나리오를 gitlab/qa/ 디렉토리에서 실행하세요. Geo 구성 단계를 건너가려면 --without-setup을 포함하세요.

    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가 여전히 셸 세션에 정의되어 있는지 확인하세요.

    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 도커 컨테이너(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 도커 컨테이너(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 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를 통해 로그인하는 오케스트레이션 테스트입니다.

이 테스트는 (osixia/openldap)에서 실행되는 OpenLDAP 인스턴스를 포함하는 Docker 컨테이너를 시작합니다.

컨테이너는 GitLab-QA 리포지토리에 체크된 픽스처를 사용하여 사용자 및 그룹과 같은 기본 데이터를 생성합니다. 여기에는 관리자 그룹이 포함됩니다. 모든 사용자의 비밀번호는 여기에서 확인할 수 있으며, tanuki 사용자의 비밀번호도 password입니다.

또한 GitLab 인스턴스가 우리의 LDAP 설정 문서를 기반으로 한 Docker 컨테이너에서 생성됩니다.

: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

    그러면 https://gitlab.test에서 Docker 컨테이너의 GitLab에 대해 테스트를 실행할 수 있습니다. 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 서버와 통합된 GitLab 인스턴스가 필요합니다. MailHog.

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 문서를 참조하세요.

카나리 대 비카나리 컴포넌트 타겟팅

QA_COOKIES ENV 변수를 사용하여 전체 테스트가 canary (staging-canary 또는 canary) 또는 non-canary (staging 또는 production) 환경을 타겟하도록 설정합니다.

로컬에서는 ENV 변수를 bin/qa 호출 앞에 추가하는 의미입니다. 해당 환경의 canary 버전을 타겟하려면:

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

대안으로, false로 쿠키를 설정하여 non-canary 버전이 타겟되도록 할 수 있습니다.

매번 앞에 추가하지 않기 위해 현재 세션에 대해 쿠키를 내보낼 수도 있습니다:

export QA_COOKIES="gitlab_canary=true"

실행 중인 스펙 내에서 쿠키 업데이트

특정 테스트 내에서, 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가 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='<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

제품 분석 테스트

제품 분석 e2e 테스트는 제품 분석 서비스가 실행되고 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 라이센스 적용.
  • SaaS 사용을 시뮬레이션합니다. 자세한 지침은 여기서 확인할 수 있습니다.

제품 분석 서비스가 실행되고 GDK에 연결되면, 테스트는 다음 명령어로 실행할 수 있습니다:

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

전역 서버 후크가 필요한 테스트

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

전역 서버 후크에 대한 자세한 정보는 서버 후크 문서에서 확인할 수 있습니다.