엔드 투 엔드 테스트 파이프라인
e2e:test-on-omnibus 자식 파이프라인
e2e:test-on-omnibus
자식 파이프라인은 GitLab 플랫폼의 E2E 테스트를 실행하는 주요 실행자입니다. 파이프라인 정의는 병합 요청 파이프라인에서 실행되는 테스트 수를 줄이기 위한 여러 동적 구성 요소를 포함하고 있습니다.
설정
파이프라인 설정은 다음으로 구성됩니다:
- 메인 GitLab 파이프라인의
prepare
단계에서e2e-test-pipeline-generate
작업. -
qa
단계에서e2e:test-on-omnibus
작업이 실행되며, 이는omnibus
패키지를 빌드하고 E2E 테스트를 실행하는 데 책임이 있는 자식 파이프라인을 트리거합니다.
e2e-test-pipeline-generate
이 작업은 선택적 테스트 실행을 구현하는 두 가지 구성 요소로 구성됩니다:
-
detect_changes
Rake 작업은 특정 병합 요청 파이프라인에서 어떤 e2e 사양을 실행해야 하는지 결정합니다. 이 작업은 특정 병합 요청의 변경 사항을 분석하고 어떤 사양을 실행해야 하는지 결정합니다. 이를 기반으로, 모든 시나리오의dry-run
이 실행되어 해당 시나리오에 실행 가능한 테스트가 포함되어 있는지 여부를 결정합니다. 선택적 테스트 실행은 이러한 기준을 사용하여 실행할 특정 테스트를 결정합니다. -
generate-e2e-pipeline
가 실행되고, 적절한 환경 변수를 가진 자식 파이프라인 YAML 정의 파일을 생성합니다.
e2e:test-on-omnibus 실행 파이프라인
E2E 테스트 실행 파이프라인은 E2E 테스트 실행을 지원하는 여러 단계로 구성됩니다.
.pre
이 단계는 다음 작업을 담당합니다:
-
병렬 테스트 실행을 지원하는
knapsack
보고서를 가져옵니다. -
omnibus-gitlab
Docker 이미지를 빌드하는 다운스트림 파이프라인을 트리거합니다.
test
이 단계는 다양한 GitLab 구성에 대해 e2e 테스트를 실행합니다. 실행되는 작업 수는 e2e-test-pipeline-generate
작업에 의해 동적으로 결정됩니다.
report
이 단계는 allure 테스트 보고서 생성을 담당합니다.
새로운 작업 추가
선택적 테스트 실행은 모든 작업 정의에 존재하는 일련의 규칙에 따라 다릅니다. 일반적인 작업은 다음 특성을 포함합니다:
variables:
QA_SCENARIO: Test::Integration::MyNewJob
rules:
- !reference [.rules:test:qa, rules]
- if: $QA_SUITES =~ /Test::Integration::MyNewJob/
- !reference [.rules:test:manual, rules]
이 예제에서:
-
QA_SCENARIO: Test::Integration::MyNewJob
:gitlab-qa
](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md) 실행자에게 전달되는 시나리오 클래스의 이름입니다. -
!reference [.rules:test:qa, rules]
: 모든 테스트를 실행해야 하는 파이프라인에 대해 일치하는 주요 규칙 정의입니다. 예를 들어,qa
프레임워크에 대한 변경 사항이 있을 때입니다. -
if: $QA_SUITES =~ /Test::Integration::MyNewJob/
: 선택적 테스트 실행을 담당하는 주요 규칙입니다.QA_SUITE
는qa 프레임워크
에 위치한 시나리오 추상화의 이름입니다.QA_SUITE
는gitlab-qa
실행자에 전달되는QA_SCENARIO
와 동일하지 않습니다. 일관성을 위해 일반적으로 동일한 이름을 가집니다.QA_SUITE
추상화 클래스는 실행할 태그에 대한 정보와 선택적으로 추가 설정 단계를 포함하는 경우가 많습니다. -
!reference [.rules:test:manual, rules]
: 항상 일치하는 마지막 규칙으로 작업을manual
로 설정하여 선택적 테스트 실행에 의해 실행되지 않더라도 요구에 따라 여전히 실행할 수 있습니다.
위 예제를 고려하여 새로운 작업을 만들기 위해 다음 단계를 수행합니다:
-
gitlab-qa
프로젝트의integration
디렉토리에 새로운 시나리오 유형my_new_job.rb
를 생성하고 새 버전을 릴리스하여 일반 사용 가능하게 만듭니다. -
qa
프레임워크의integration
디렉토리에 새로운 시나리오my_new_job.rb
를 생성합니다. 가장 단순한 경우, 이 시나리오는 실행되어야 하는 RSpec 태그를 정의합니다:
module QA
module Scenario
module Test
module Integration
class MyNewJob < Test::Instance::All
tags :some_special_tag
end
end
end
end
end
-
main.gitlab-ci.yml
파이프라인 정의에 새로운 작업 정의를 추가합니다:ee:my-new-job: extends: .qa variables: QA_SCENARIO: Test::Integration::MyNewJob rules: - !reference [.rules:test:qa, rules] - if: $QA_SUITES =~ /Test::Integration::MyNewJob/ - !reference [.rules:test:manual, rules]
병렬 작업
선택적 실행이 여러 병렬 작업을 실행해야 하는 작업 유형과 함께 올바르게 작동하려면, 작업 정의는 일반적으로 병렬 및 선택적 변형으로 나누어져야 합니다. 나누는 것은 선택적 실행이 단일 사양만 실행할 때 불필요한 여러 작업이 생성되지 않도록 하기 위해 필요합니다. 예를 들어:
ee:my-new-job-selective:
extends: .qa
variables:
QA_SCENARIO: Test::Integration::MyNewJob
rules:
- !reference [.rules:test:qa-selective, rules]
- if: $QA_SUITES =~ /Test::Integration::MyNewJob/
ee:my-new-job:
extends:
- .parallel
- ee:my-new-job-selective
rules:
- !reference [.rules:test:qa-parallel, rules]
- if: $QA_SUITES =~ /Test::Integration::MyNewJob/
e2e:test-on-gdk
e2e:test-on-gdk
자식 파이프라인은 GitLab 플랫폼의 개발을 지원하여 엔지니어에게
e2e:test-on-omnibus
보다 더 빠르게 종단 간 테스트 실행에 대한 피드백을 제공합니다.
이는 GitLab Development Kit (GDK)에 대해 테스트를 실행함으로써 달성되며, 이는 Omnibus GitLab에 대해 테스트하는 것보다 더 짧은 시간 내에 빌드되고 설치될 수 있습니다. Trade-off는 Omnibus GitLab이 프로덕션 설치를 배포하는 데 사용될 수 있는 반면, GDK는 개발 환경이라는 것입니다. GDK에 대해 실행되는 테스트는 GitLab을 프로덕션 환경에서 실행하기 위해 준비하는 과정의 일부에 의존하는 버그를 잡아내지 못할 수 있으며, 여기에는 자산을 사전 컴파일하고, 공식 설치 패키지의 일환으로 구성 기본값을 할당하고, 여러 서버에 GitLab 서비스를 배포하는 것이 포함됩니다. 반면, 매일 GDK를 사용하는 엔지니어들은 GDK에서만 나타나는 버그를 자동화된 테스트가 잡아내는 혜택을 볼 수 있습니다.
설정
파이프라인 설정은 기본 GitLab 파이프라인의 여러 작업으로 구성됩니다:
-
e2e-test-pipeline-generate
작업 인prepare
단계입니다. 이는e2e:test-on-omnibus
파이프라인에서와 동일한 작업입니다. -
build-gdk-image
작업 인build-images
단계입니다. -
qa
단계의e2e:test-on-gdk
트리거 작업으로, 이는 E2E 테스트를 실행하는 자식 파이프라인을 트리거합니다.
build-gdk-image
이 작업은 병합 요청의 코드를 사용하여 GDK 인스턴스를 컨테이너에서 실행할 수 있는 Docker 이미지를 빌드합니다. 이미지는 컨테이너 레지스트리에 푸시됩니다.
이 작업은 기본 브랜치의 파이프라인에서도 실행되어 GDK 및 GitLab 구성 요소를 포함한 기본 이미지를 빌드합니다. 이를 통해 병합 요청에서 전체 이미지를 처음부터 끝까지 빌드하는 것을 피할 수 있습니다. 그러나 병합 요청에 특정 GitLab 구성 요소 또는 코드에 대한 변경이 포함된 경우, 작업은 테스트 작업에 사용될 이미지를 빌드하기 전에 기본 이미지를 재빌드합니다.
e2e:test-on-gdk
자식 파이프라인
e2e:test-on-omnibus
파이프라인과 마찬가지로, e2e:test-on-gdk
파이프라인은 E2E 테스트 실행을 지원하는 여러 단계로 구성되어 있습니다.
.pre
이 단계는 병렬 테스트 실행을 지원하는 knapsack
보고서를 가져오는 책임을 집니다.
test
이 단계는 다양한 유형의 GitLab 구성에 대해 e2e 테스트를 실행합니다. 실행되는 작업의 수는
e2e-test-pipeline-generate
작업에 의해 동적으로 결정됩니다.
각 작업은 build-gdk-image
작업에서 생성된 GDK Docker 이미지에서 컨테이너를 시작한 다음,
컨테이너에서 실행 중인 GDK 인스턴스에 대해 엔드 투 엔드 테스트를 실행합니다.
report
이 단계는 allure 테스트 보고서 생성을 담당합니다.
e2e:test-on-cng
e2e:test-on-cng
자식 파이프라인은 Cloud Native GitLab 설치에 대해 테스트를 실행합니다.
review-apps
와는 달리, 이 파이프라인은 로컬 kind Kubernetes 클러스터를 사용합니다.
배포는 cng
오케스트레이터 도구에 의해 관리되며, 이를 사용하여 로컬 CI/CD 배포를 재현할 수도 있습니다.
이 파이프라인은 정기 파이프라인에서 매 2시간마다 실행되며 다음 검증을 수행합니다:
- 기본 차트 구성을 사용한
CNG
배포에 대한 주요 테스트 스위트. - 최소 지원되는
redis
버전을 사용하는CNG
배포에 대한 최소health_check
테스트 스위트.
설정
파이프라인 설정은 주요 GitLab 파이프라인의 여러 작업으로 구성됩니다:
-
compile-production-assets
및build-assets-image
작업은 CNG 빌드 파이프라인에 필요한 프론트엔드 자산을 컴파일하는 책임을 집니다. -
e2e-test-pipeline-generate
작업은e2e:test-on-cng
자식 파이프라인 생성을 담당합니다.
e2e:test-on-cng
자식 파이프라인
자식 파이프라인은 E2E 테스트 실행을 지원하는 여러 단계로 구성됩니다.
.pre
-
build-cng-env
작업은 CNG 하위 파이프라인에 대한 모든 환경 변수를 설정하는 책임을 집니다. -
build-cng
작업은 모든 필요한 이미지를 구축하는 책임이 있는CNG
하위 파이프라인을 트리거합니다.
test
test
단계의 작업은 다음 작업을 수행합니다:
-
kind
를 사용한 로컬 k8s 클러스터 설정 - 공식
helm
chart를 사용한 GitLab 설치 - 수행된 배포에 대한 E2E 테스트 실행
report
이 단계는 allure 테스트 보고서 생성 및 테스트 메트릭 업로드를 담당합니다.
디버깅
디버깅을 돕기 위해:
- 각 테스트 작업은 로컬 디버깅을 위해 동일한 배포를 정확히 재현할 수 있도록
cng
오케스트레이터에 전달할 수 있는 인수 목록을 출력합니다. - 클러스터 이벤트 로그 및 모든 포드 로그는 E2E 테스트 작업 아티팩트에 저장됩니다.