젠킨스 스펙
- 문제 해결
Gitaly 클러스터 테스트
러너가 필요한 테스트
Geo 테스트
- Geo GDK 사용
- Docker 내의 Geo 사용
  - 노트
그룹 SAML 테스트
인스턴스 SAML 테스트
LDAP 테스트
- TLS를 활성화한 상태에서 LDAP 테스트 실행
- TLS를 비활성화한 상태에서 LDAP 테스트 실행
SMTP 테스트
모바일 스위트 가이드
라이브 환경에서 카나리와 비-카나리 컴포넌트를 타겟팅하는 방법
- 실행 중인 spec 내에서 쿠키 업데이트하기
GitLab에서 OpenID Connect (OIDC) 및 OAuth 제공자로서의 테스트
제품 분석 테스트

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

젠킨스 스펙

jenkins_build_status_spec는 Jenkins GitLab 플러그인이 사전 설치된 Docker 컨테이너에서 Jenkins 인스턴스를 시작합니다. 라이선스 제한으로 인해 해당 이미지를 배포할 수 없습니다. QA 호환 이미지를 빌드하려면, 제 3자 Dockerfile을 찾을 수 있는 제3자 이미지 프로젝트를 방문하세요. 프로젝트에는 포킹 및 이미지를 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를 참조하세요: 제3자 이미지 프로젝트

문제 해결

Jenkins Docker 컨테이너가 로그에서 어떤 정보도 제공하지 않고 종료된 경우, Docker Engine에서 사용하는 메모리를 늘리는 것을 시도해 보세요.

Gitaly 클러스터 테스트

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

상기된 시나리오에 대한 문서에서 다음의 명령이 테스트를 실행합니다:

gitlab-qa Test::Integration::GitalyCluster EE

그러나 해당 명령은 테스트를 실행한 후 컨테이너를 제거합니다. Debugger를 통해 단일 테스트를 실행하거나 추가적인 테스트를 수행하고자 하는 경우 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을 통해 수행됩니다. 이 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 인스턴스를 만들 때, 특정 인터페이스 IP 주소나 러너 컨테이너에서 접근 가능한 로컬 호스트 이름을 Docker run 명령어의 --hostname 매개변수에 지정해야 합니다. GitLab 호스트 이름으로 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 인터페이스_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

여기서 interface_ip_address는 로컬 네트워크의 인터페이스 IP로, ifconfig 명령어로 찾을 수 있습니다. GDK에서도 인스턴스 주소를 localhost로 설정하는 경우도 동일합니다.

Geo 테스트

Geo end-to-end 테스트는 로컬에서 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)과 같은 역방향 프록시 서버가 필요합니다.

EE 라이선스 내보내기

export EE_LICENSE=$(cat <your/gitlab_license/의/경로>)

선택 사항. 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
```
Test::Integration::Geo 조정된 시나리오를 --no-teardown 옵션과 함께 실행하여 GitLab 컨테이너를 빌드하고 Geo 설정을 구성하고 Geo end-to-end 테스트를 실행합니다. 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=여기에_토큰_추가 gitlab-qa Test::Integration::Geo registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:examplesha123456789 --no-teardown
```
--no-tests 옵션을 사용하여 컨테이너를 먼저 빌드하고, 그런 다음 GDK와 컨테이너가 다른 GitLab 버전을 기반으로 할 때 EE::Scenario::Test::Geo 시나리오를 실행할 수 있습니다. --no-teardown 옵션을 사용하면 GitLab-QA는 같은 GitLab 버전을 사용하여 Geo 설정을 구성합니다.

브라우저에서 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

로컬 GDK에서 end-to-end 테스트를 실행하려면, GDK의 qa/ee/scenario/test/geo.rb에서 [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 end-to-end 테스트를 실행해야 합니다. 쉘 세션에서 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
```

컨테이너 중지 및 제거

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를 대상으로 이러한 테스트를 실행하려면 다음을 수행하세요:

gitlab.yml 파일에 다음 설정을 추가하세요:

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

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 젬을 사용하여 이러한 테스트를 실행하는 방법에 대한 지침은 GitLab QA 문서를 참조하십시오.

인스턴스 SAML 테스트

:instance_saml 메타로 태그 지정된 테스트들은 SAML SSO를 통해 인스턴스 수준의 로그인이 발생하는 조정된 테스트입니다.

이러한 테스트들은 구성 및 실행 중인 SAML IDP 도커 컨테이너(jamedjo/test-SAML-idp)가 필요합니다.

컴퓨터에서 GDK를 대상으로 이러한 테스트를 실행하려면 다음을 수행하세요:

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'
    } }

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

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 젬을 사용하여 이러한 테스트를 실행하는 방법에 대한 지침은 GitLab QA 문서를 참조하십시오.

LDAP 테스트

:ldap_tls 및 :ldap_no_tls 메타로 태그 지정된 테스트들은 LDAP를 통해 로그인하는 조정된 테스트입니다.

이러한 테스트들은 (osixia/openldap)를 실행하여 OpenLDAP의 인스턴스를 실행하는 Docker 컨테이너를 실행합니다. 컨테이너는 사용자 및 관리자 그룹을 포함한 사용자 및 그룹과 같은 기본 데이터를 생성하기 위해 GitLab-QA 리포지터리에 체크인된 fixtures를 사용합니다. 모든 사용자 및 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 테스트를 실행하려면 다음 단계를 따르세요:

/etc/hosts 파일에 다음 항목을 포함시킵니다:
127.0.0.1 gitlab.test
그런 다음 https://gitlab.test의 도커 컨테이너에서 GitLab에 대한 테스트를 실행할 수 있습니다. 이 도메인을 위해 GitLab-QA 리포지터리에 확인된 TLS 인증서가 구성되어 있습니다.

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

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

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 테스트를 실행하려면 다음 단계를 따르세요:

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

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

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 서버인 MailHog와 통합된 환경을 필요로 합니다.

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

gitlab.yml 파일에 다음 설정을 추가하세요:

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

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

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 Installation을 참조하세요. 설치 후 터널을 시작하려면 1Password에서 찾은 자격증명을 사용하여 Sauce Labs에 로그인한 후 Tunnels 섹션에서 실행 명령어를 복사하여 터미널에서 실행하세요.

GITLAB_QA_ACCESS_TOKEN을 사용하여 테스트 속도를 높이고, 안정성을 높이는 것이 강력히 추천됩니다.

QA_REMOTE_MOBILE_DEVICE_NAME은 Supported browsers and devices의 Emulators/simulators 아래 나열된 장치 중 하나여야 합니다. QA_BROWSER는 iOS 장치의 경우 safari, Android 장치의 경우 chrome으로 설정되어야 합니다.

터널이 실행 중인 로컬 환경에서 테스트하려면 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://<local_ip>:3000 -- <relative_spec_path>

결과는 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

모바일 레이아웃일 경우 기존 페이지 객체에 새 모바일을 prepending:

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입니다. 이는 휴대폰 레이아웃이 기본적으로 더 많은 메뉴를 닫고 있다면 태블릿과 휴대폰이 모두 왼쪽 내비게이션을 닫지만, 휴대폰 레이아웃과 달리 태블릿은 모바일 상단 내비게이션 바가 아니라 일반적인 상위 내비게이션 바를 가지고 있기 때문입니다. 따라서 편집하는 네비게이션을 태블릿 레이아웃에서도 사용해야 하는 경우 prepending할 때 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>

대안으로 현재 세션에 대한 cookie를 미리 설정하여 매번 앞에 놓지 않도록할 수 있습니다:

export QA_COOKIES="gitlab_canary=true"

실행 중인 spec 내에서 쿠키 업데이트하기

특정 테스트 내에서 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 노드로 리디렉션하는지 확인할 수 있습니다.

위의 spec은 상세한 편이며, 구현 아이디어가 명확히 이해될 수 있도록 특별히 작성되었습니다. 초보자를 위한 엔드투엔드 테스트 작성 가이드의 지침을 따르는 것을 권장합니다.

GitLab에서 OpenID Connect (OIDC) 및 OAuth 제공자로서의 테스트

로컬 머신에서 login_via_oauth_and_oidc_with_gitlab_as_idp_spec을 실행하려면:

GDK가 gdk.test:3000과 같은 로컬호스트가 아닌 주소로 설정되어 있는지 확인하세요.
172.16.123.1로의 루프백 인터페이스를 구성.
Docker Desktop 또는 Rancher Desktop이 실행 중인지 확인하세요.
gitlab-oidc-consumer.bridge 및 gitlab-oauth-consumer.bridge에 대한 /etc/hosts 파일에 127.0.0.1을 가리키는 항목을 추가하세요.

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

Ultimate 라이선스 적용.
- 라이선스 요청 방법.
- 라이선스 파일 또는 키로 GitLab EE 활성화하는 방법.
제품 분석 피처 플래그 활성화. 플래그 디렉터리은 여기에서 찾을 수 있습니다.
SaaS 시뮬레이션 활성화. 지침은 여기에서 찾을 수 있습니다.

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

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

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

젠킨스 스펙

문제 해결

Gitaly 클러스터 테스트

러너가 필요한 테스트

Geo 테스트

Geo GDK 사용

Docker 내의 Geo 사용

노트

그룹 SAML 테스트

인스턴스 SAML 테스트

LDAP 테스트

TLS를 활성화한 상태에서 LDAP 테스트 실행

TLS를 비활성화한 상태에서 LDAP 테스트 실행

SMTP 테스트

모바일 스위트 가이드

모바일 테스트란

Sauce Labs를 사용하여 모바일 테스트 실행하기

기존 테스트를 모바일 스위트에 추가하는 방법

라이브 환경에서 카나리와 비-카나리 컴포넌트를 타겟팅하는 방법

실행 중인 spec 내에서 쿠키 업데이트하기

GitLab에서 OpenID Connect (OIDC) 및 OAuth 제공자로서의 테스트

제품 분석 테스트

도움말

기능 사용 가능성과 제품 평가판

도움받기