• Jenkins 스펙
  • 문제 해결
• Gitaly 클러스터 테스트
• Runner가 필요한 테스트
• Geo 테스트
  • Geo GDK 사용
  • Docker에서 Geo 사용
    • 노트
• 그룹 SAML 테스트
• 인스턴스 SAML 테스트
• LDAP 테스트
  • TLS로 활성화된 LDAP 테스트 실행
  • TLS 비활성화 상태에서 LDAP 테스트 실행
• SMTP 테스트
• 모바일 스위트 가이드
  • 모바일 테스트란
  • Sauce Labs를 사용하여 모바일 테스트 실행하기
  • 기존 테스트를 모바일 스위트에 추가하는 방법
• 캐너리 대 비-캐너리 컴포넌트를 라이브 환경에서 타게팅하기
  • 실행 중인 스펙 내에서 쿠키 업데이트하기
• GitLab을 OpenID Connect (OIDC) 및 OAuth 제공자로 하는 테스트
• 제품 분석 테스트

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

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 (이 사용자의 인증을 위한 암호/토큰)

테스트는 Jenkins에서 GitLab 플러그인을 구성하여 테스트를 실행하는 데 사용되는 GitLab 인스턴스의 URL로 진행됩니다. GitLab 인스턴스와 Jenkins 간에 상호 네트워킹이 필요하므로 GitLab도 Docker 컨테이너에서 시작될 수 있어야 합니다.

Nighlty 이미지를 기반으로 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 컨테이너를 자동으로 생성하고 테스트가 완료되면 제거됩니다.

테스트를 수동으로 실행해야 하는 경우 테스트 이외의 행동을 수행하려면 서드 파티 이미지 프로젝트의 README를 참조하세요.

문제 해결

Jenkins Docker 컨테이너가 로그에서 정보를 제공하지 않고 종료되는 경우 Docker Engine에서 사용하는 메모리를 늘려보세요.

Gitaly 클러스터 테스트

: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로 설정됩니다. 테스트를 실행하기 전에 컴퓨터를 해당 주소를 통해 컨테이너에 액세스하도록 구성해야 합니다. 이를 위한 하나의 옵션은 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

Runner가 필요한 테스트

Runner를 사용하는 테스트를 실행하려면 GitLab Docker 인스턴스를 만들 때 Docker run 명령에 --hostname 매개변수를 특정 인터페이스 IP 주소 또는 루프백이 아닌 호스트 이름을 지정해야 합니다. localhost (또는 127.0.0.1)를 GitLab 호스트 이름으로 사용하면 작동하지 않습니다(단, 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 인터페이스_IP_주소 \
  --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

여기서 인터페이스_IP_주소는 로컬 네트워크의 인터페이스 IP로, ifconfig명령어로 찾을 수 있습니다. 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-QA Orchestrator를 사용하여 두 개의 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 종단 간 테스트를 실행합니다. 테스트를 중지한 후에도 컨테이너는 계속 실행됩니다.

   # 가장 최신 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 시나리오를 실행하고 Geo 구성 단계를 건너뛸 수 있습니다. 그러나 GDK와 컨테이너가 다른 GitLab 버전을 기반으로 하면 구성 문제가 발생할 수 있습니다. --no-teardown 옵션을 사용하면 GitLab-QA는 GitLab 컨테이너 및 Geo 설정을 구성하는 데 동일한 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에서 종단 간 테스트를 실행하려면 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가 정의되어 있는지 확인하세요.

   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 변수를 설정하라는 프롬프트를 받을 수 있습니다.
• 복제 대기 시간을 120초로 설정하여 복제 대기 시간을 늘릴 수 있습니다. 이를 위해 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 리포지토리에 체크인된 fixtures를 사용하여 사용자 및 관리자 그룹을 포함한 사용자 및 그룹과 같은 기본 데이터를 생성합니다. 모든 사용자의 비밀번호는 password입니다. 또한 인증서 생성을 기반으로 Docker 컨테이너에서 GitLab 인스턴스도 생성됩니다.

: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에 대한 테스트를 실행할 수 있습니다. 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

1. 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

1. 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 메타 태그가 지정된 테스트는 사용자가 이메일 알림을 수신하는지 확인하는 조정된 테스트입니다.

이러한 테스트를 로컬에서 GDK를 통해 실행하려면:

1. gitlab.yml 파일에 다음 설정을 추가합니다:

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

1. 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

1. 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 설치를 참조하십시오. 설치 후 터널을 시작하려면 Sauce Labs > Tunnels에 로그인하여 터널에서 찾은 자격 증명을 사용하여 터미널에서 실행하십시오.

참고: GITLAB_QA_ACCESS_TOKEN을 사용하여 테스트를 가속화하고 불안정성을 줄이는 것이 매우 좋습니다.

QA_REMOTE_MOBILE_DEVICE_NAME은 지원되는 브라우저 및 기기의 Emulators/simulators 하위에서 나열된 장치 이름 중 하나여야 합니다. 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="<Sauce Lab 계정에서 찾음>" \
  GITLAB_QA_ACCESS_TOKEN="<토큰>" \
  bundle exec bin/qa Test::Instance::All http://<로컬_아이피>:3000 -- <상대적_스펙_경로>

결과는 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만 true입니다. 이는 휴대폰 레이아웃이 기본적으로 더 많은 메뉴를 닫아 둔 상태인 반면, 태블릿과 휴대폰은 왼쪽 탐색은 닫힌 채로 유지하지만 휴대폰 레이아웃과 달리 태블릿에는 일반적인 상단 탐색 막대가 있기 때문입니다. 따라서 편집 중인 탐색이 태블릿 레이아웃에서도 사용되어야 하는 경우 앞부분에 추가할 때 mobile_layout? 대신 remote_mobile_device_name을 사용하여 사용하도록 해야 합니다.

캐너리 대 비-캐너리 컴포넌트를 라이브 환경에서 타게팅하기

QA_COOKIES 환경 변수를 사용하여 전체 테스트가 canary (staging-canary 또는 canary) 또는 non-canary (staging 또는 production) 환경을 타게팅하도록 할 수 있습니다.

로컬에서는 bin/qa를 호출하는 호출 부분에 ENV 변수를 앞부분에 추가하여 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 'tests toggling between canary and non-canary nodes' 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 'testing session log in' 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. gitlab-oidc-consumer.bridge 및 gitlab-oauth-consumer.bridge을 127.0.0.1로 가리키도록 /etc/hosts 파일에 항목을 추가합니다.

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에는 다음 설정이 필요합니다.

• 얼티메이트 라이선스가 적용되어 있어야 함.
  • 라이선스를 요청하는 방법.
  • 라이선스 파일 또는 키로 GitLab EE를 활성화하는 방법.
• 제품 분석 기능 플래그가 활성화되어 있어야 함. 기능 플래그 목록은 여기에서 찾을 수 있습니다.
• SaaS 시뮬레이션 활성화 필요. 지침은 여기에서 찾을 수 있습니다.

제품 분석 서비스가 실행되고 GDK에 연결된 경우 다음 명령을 사용하여 테스트를 실행할 수 있습니다.

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