- Jenkins spec
- Gitaly Cluster 테스트
- Runner가 필요한 테스트
- Geo 테스트
- 그룹 SAML 테스트
- 인스턴스 SAML 테스트
- LDAP 테스트
- SMTP 테스트
- 라이브 환경에서 카나리 대 카나리되지 않는 컴포넌트를 대상으로하는 테스트
- GitLab로 OpenID Connect (OIDC) 및 OAuth 제공자로서의 테스트
- 제품 분석 테스트
특별한 설정이 필요한 테스트 실행
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)가 필요합니다.
-
EE 라이선스를 내보내기하세요
export EE_LICENSE=$(cat <path/to/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
-
--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 버전을 사용합니다. -
브라우저에서 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에서 종단간 테스트를 실행하려면
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
-
컨테이너 정지 및 제거
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에서 컴퓨터에서 이러한 테스트를 실행하려면:
-
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
gem을 사용하여 이러한 테스트를 실행하는 방법에 대한 지침은 GitLab QA 문서를 참조하십시오.
인스턴스 SAML 테스트
:instance_saml
메타로 태그가 지정된 테스트는 인스턴스 수준 로그인이 SAML SSO를 사용하여 조정된 테스트입니다.
이러한 테스트에는 SAML IDP Docker 컨테이너(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 컨테이너를 시작하십시오.
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
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 테스트를 실행하려면 다음 단계를 따르십시오:
-
/etc/hosts
파일에 다음 항목을 포함하십시오:127.0.0.1 gitlab.test
그런 다음 Docker 컨테이너에서
https://gitlab.test
에 대해 GitLab 테스트를 실행할 수 있습니다. TLS 인증서 GitLab-QA 리포지터리는 이 도메인을 위해 구성되었습니다. -
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
메타 태그로 태그가 지정된 테스트는 사용자가 이메일 알림을 받는지 확인하는 조정된 테스트입니다.
이러한 테스트를 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
젬을 사용하여 이러한 테스트를 실행하는 방법에 대한 지침은 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
를 실행하려면 다음 단계를 따르세요:
- 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에 다음 설정이 필요합니다.
-
제품 분석 구성을 위한 환경 변수 설정. 다음 변수는 로컬에서 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