• 젠킨스 스펙
  • 문제 해결
• Gitaly 클러스터 테스트
• 러너가 필요한 테스트
• Geo 테스트
  • Geo GDK 사용
  • Docker에서 Geo 사용
    • 참고 사항
• 그룹 SAML 테스트
• 인스턴스 SAML 테스트
• LDAP 테스트
  • TLS 활성화된 상태에서 LDAP 테스트 실행하기
  • TLS 비활성화된 상태에서 LDAP 테스트 실행하기
• SMTP 테스트
• 라이브 환경에서 케너리 대 비케너리 구성 요소 타깃팅
  • 실행 중인 특정 명세에서 쿠키 업데이트
• GitLab의 OpenID Connect (OIDC) 및 OAuth 제공자용 테스트
• 제품 분석 테스트
• 글로벌 서버 훅이 필요한 테스트

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

젠킨스 스펙

jenkins_build_status_spec는 젠킨스 GitLab 플러그인이 사전 설치된 Docker 컨테이너에서 Jenkins 인스턴스를 생성합니다. 라이선스 제약으로 인해 해당 이미지를 배포할 수 없습니다. 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 컨테이너에서 시작될 수 있어야 합니다.

매일 이미지를 기반으로 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 클러스터 테스트

:gitaly_ha 태그가 지정된 테스트는 GitLab QA 시나리오의 Test::Integration::GitalyCluster로 시작되는 테스트로 구성되고 시작된 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을 통해 수행됩니다. 이는 본 예제에서 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 run 명령에 --hostname 매개변수에 고유한 인터페이스 IP 주소 또는 러너 컨테이너에서 접근 가능한 루프백이 아닌 호스트 이름을 제공해야 합니다. localhost (또는 127.0.0.1)를 GitLab 호스트 이름으로 사용하면 작동하지 않습니다(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 명령으로 찾을 수 있습니다. GDK를 사용할 때도 인스턴스 주소를 localhost로 지정하는 경우 동일한 적용이 됩니다.

Geo 테스트

Geo 종단 간 테스트는 로컬에서 Geo GDK 설치 또는 Docker 컨테이너에서 실행할 수 있습니다.

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 이미지 가져오기

   이 단계는 이미지를 다운로드하는 것이 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 시나리오를 실행할 수도 있습니다. 그러나 GDK와 컨테이너가 서로 다른 GitLab 버전을 기반으로 할 경우 구성 문제가 발생할 수 있습니다. --no-teardown 옵션을 사용하여, GitLab-QA는 GitLab 컨테이너 및 Geo 설정을 구성할 때 동일한 GitLab 버전을 사용합니다.

4. 브라우저에서 Geo 사이트를 방문하려면 컨테이너 내부에서 사용되는 호스트 이름에 대한 요청을 로컬 IP로 프록시해야 합니다. 이 예제에서는 역방향 프록시 서버로 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=[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 시나리오를 실행하여 먼저 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. 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) Docker 컨테이너를 실행하여 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

   그런 다음 Docker 컨테이너에서 https://gitlab.test로 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가 활성화된 GitLab 인스턴스와 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 젬을 사용하여 이러한 테스트를 실행하는 방법에 대한 지침은 GitLab QA 문서를 참조하십시오.

라이브 환경에서 케너리 대 비케너리 구성 요소 타깃팅

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 '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. 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을 사용할 수 있습니다. 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
  

• 얼티메이트 라이선스 적용.
  • 라이선스 요청 방법.
  • 라이선스 파일 또는 키로 GitLab EE를 활성화하는 방법.
• 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

글로벌 서버 훅에 대한 자세한 정보는 서버 훅 문서에서 찾을 수 있습니다.