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

Jenkins spec

jenkins_build_status_spec은 Jenkins GitLab 플러그인이 사전 설치된 Docker 컨테이너 내에서 Jenkins 인스턴스를 켭니다. 이미지를 배포할 수 없는 라이선스 제한 때문에 QA 호환 이미지를 빌드하려면 third party images project를 방문하면 됩니다. 이 프로젝트에는 퍼스트 파티 도커 파일을 찾을 수 있으며, 포크 및 이미지를 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 인스턴스와 젠킨스 간에 상호 네트워킹이 필요하므로 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

이 테스트는 젠킨스를 자동으로 실행하고 테스트를 완료하면 종료합니다.

테스트를 매뉴얼으로 실행해야 할 경우, README를 참조하여 third party images project에서 설명하는 대로 실행할 수 있습니다.

문제 해결

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

Gitaly Cluster 테스트

:gitaly_ha로 태그가 지정된 테스트들은 the Test::Integration::GitalyCluster GitLab QA 시나리오로 설정되고 시작된 Docker 컨테이너 세트에서만 실행할 수 있는 조정된 테스트입니다.

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

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

이는 http://localhost:32772를 통해 gitlab-gitaly-cluster 컨테이너에서 실행 중인 GitLab 인스턴스에 액세스할 수 있음을 보여줍니다. 그러나 클론 및 푸시와 같은 Git 작업은 UI에서 클론 URL로 공개된 URL을 통해 수행됩니다. 이는 이 경우 Docker 컨테이너 이름 및 네트워크에 구성된 호스트 이름을 사용합니다. 테스트를 실행하기 전에 컴퓨터를 해당 주소를 통해 컨테이너에 액세스할 수 있도록 구성해야 합니다. 이를 위한 한 가지 방법은 GDK에서 테스트를 실행하는 방법에 설명된대로 Caddy 서버를 사용하는 것이고, 또 다른 방법은 NGINX를 사용하는 것입니다.

두 경우 모두 컴퓨터가 gitlab-gitaly-cluster.test를 적절한 IP 주소로 변환하도록 구성해야 합니다.

그런 다음 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 주소나 루프백이 아닌 호스트 이름을 지정해야 합니다. 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-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 옵션을 사용하여 컨테이너만 빌드한 다음 EE::Scenario::Test::Geo 시나리오를 실행하여 GDK에서 Geo 구성 단계를 건너뛰고 테스트를 실행할 수 있습니다. 그러나 GDK와 컨테이너가 다른 GitLab 버전을 기반으로 하고 있는 경우 구성 문제가 발생할 수 있습니다. --no-teardown 옵션을 사용하면 GitLab-QA는 GitLab 컨테이너와 Geo 설정을 구성하는 데 사용하는 GitLab QA 컨테이너에 동일한 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 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를 통해 로그인이 발생하는 조정된 테스트입니다.

이러한 테스트는 (osixia/openldap) Docker 컨테이너를 실행하여 OpenLDAP의 인스턴스를 실행합니다. 컨테이너는 GitLab-QA 리포지터리에 체크인된 fixtures를 사용하여 사용자 및 그룹(관리자 그룹 포함)과 같은 기본 데이터를 작성합니다. 모든 사용자 및 the tanuki 사용자의 비밀번호는 password입니다.

LDAP 테스트에 :ldap_tls로 태그가 지정되면 GitLab에서 GitLab-QA 리포지터리에 체크인된 인증서를 사용하여 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 메타 태그로 태그가 지정된 테스트는 사용자가 이메일 알림을 받는지 확인하는 조정된 테스트입니다.

이러한 테스트를 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 호출 전에 환경 변수를 추가해야 합니다. 해당 환경의 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"

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

특정 테스트 내에서 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에 대한 /etc/hosts 파일에 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 라이선스 적용.
    • 라이선스 신청 방법은 여기에서 찾을 수 있습니다.
    • 라이선스 파일 또는 키로 GitLab EE를 활성화하는 방법은 여기에서 찾을 수 있습니다.
  • SaaS 시뮬레이션 활성화됨. 지침은 여기에서 찾을 수 있습니다.

제품 분석 서비스가 실행되고 GDK에 연결된 후에는 다음과 같이 테스트를 실행할 수 있습니다. 

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