공통 아키텍처#

모든 E2E 테스트는 별도의 하위 파이프라인 내에서 실행됩니다. E2E 테스트 파이프라인의 다양한 동적 기능을 지원하기 위해, 모든 하위 파이프라인 YAML 파일은 e2e-test-pipeline-generate CI/CD job에 의해 생성되며, 각각의 트리거 job에 의해 실행됩니다.

e2e-test-pipeline-generate#

e2e-test-pipeline-generate job은 E2E 테스트를 실행하는 하위 파이프라인을 트리거하는 데 사용되는 CI/CD YAML 파일 정의를 생성합니다.

generate_e2e_pipelines Rake 태스크는 다음을 수행합니다:

• 특정 머지 리퀘스트 파이프라인에서 실행해야 할 e2e 스펙을 결정합니다.

• 각 E2E 테스트 파이프라인 유형에 대한 CI/CD YAML 파일 정의를 생성합니다.

이 Rake 태스크는 다음을 수행합니다:

• 특정 머지 리퀘스트의 변경 사항을 분석하고, 다음 기준을 사용하는 선택적 테스트 실행을 통해 어떤 스펙을 실행해야 하는지 결정합니다. 이를 바탕으로 모든 시나리오의 dry-run이 실행되어 시나리오에 실행 가능한 테스트가 포함되어 있는지 확인합니다.

• 각 시나리오의 총 실행 시간이 계산됩니다.

• 실행 시간 값을 기반으로, 동적 job 스케일링이 각 시나리오 유형에 필요한 병렬 CI/CD job 수를 계산하고 적절한 값으로 파이프라인 YAML 파일을 생성합니다.

e2e:perf-on-cng#

e2e:perf-on-cng 하위 파이프라인은 Cloud Native GitLab 설치 환경에 대해 테스트를 실행합니다.

배포는 orchestrator CLI 도구로 관리되며, 이를 사용하여 CI/CD 배포를 로컬에서 재현할 수도 있습니다.

e2e:perf-on-cng 하위 파이프라인은 머지 리퀘스트에서 실행되며 non-blocking job입니다. 테스트가 실패해도 머지 리퀘스트 병합을 차단하지 않습니다.

Setup#

이 E2E 테스트 하위 파이프라인은 e2e-test-pipeline-generate CI/CD job의 아티팩트로 저장된 동적으로 생성된 CI/CD YAML 파일을 사용하여 e2e:perf-on-cng job에 의해 트리거됩니다. CI/CD YAML 파일은 템플릿을 사용하여 생성됩니다.

하위 파이프라인 job#

하위 파이프라인은 E2E 테스트 실행을 지원하는 여러 Stage로 구성됩니다.

.pre#

• build-cng-env job은 CNG 다운스트림 파이프라인을 위한 모든 환경 변수를 설정합니다.

• build-cng job은 필요한 모든 이미지를 빌드하는 CNG 다운스트림 파이프라인을 트리거합니다.

prepare#

• dotenv-vars job은 모든 k6 성능 테스트로 구성된 qa/performance_test 폴더에서 아티팩트를 생성합니다. 이 아티팩트는 테스트를 실행하기 위해 다운스트림 파이프라인 job에 의해 다운로드됩니다. 또한 job 정의에서 볼 수 있듯이 CI_JOB_NAME, CI_JOB_ID, GITLAB_HELM_CHART_REF와 같은 일부 환경 변수를 저장하며, 이는 run-performance-tests job에서 사용됩니다.

test#

run-performance-test job#

이 job은 Component Performance testing 프로젝트에서 다운스트림 멀티 프로젝트 파이프라인을 트리거합니다. 이 파이프라인은 다음 작업을 수행합니다:

• 동일한 리전 및 영역에 두 개의 gpc 인스턴스를 생성합니다.

server 인스턴스: orchestrator를 사용하여 GitLab의 CNG 인스턴스가 생성되는 곳

kind를 사용한 로컬 k8s 클러스터 Setup

• 공식 helm 차트를 사용한 GitLab 설치

• test runner 인스턴스: dotenv-vars job의 아티팩트로 다운로드된 k6 테스트를 실행하고 server 인스턴스에서 생성된 CNG GitLab 인스턴스에 대해 테스트를 실행합니다.

새 테스트 추가#

run-performance-test job의 일부로 실행될 새 k6 테스트를 추가할 수 있습니다.

새 테스트를 추가하려면:

• qa/performance_test/k6_test 하위에 새 .js 파일을 생성합니다.

• 테스트 작성을 시작하기 전에 다음 보일러플레이트를 복사하여 붙여넣습니다.

• 해당하는 값과 코드로 주석 섹션을 업데이트합니다.

export const TTFB_THRESHOLD= /* TTFB THRESHOLD VALUE EXPECTED */;
export const RPS_THRESHOLD= /* RPS THRESHOLD VALUE EXPECTED */;
export const TEST_NAME=/* 'NAME OF THE TEST IN QUOTES' */;
export const LOAD_TEST_VUS = 2; /* THE NUMBER OF THREADS OF ACTUAL TEST */
export const LOAD_TEST_DURATION = '50s'; /* THE DURATION FOR THE ACTUAL TEST RUN */
export const WARMUP_TEST_VUS = 1; /* THE NUMBER OF THREADS FOR WARMING UP THE SYSTEM */
export const WARMUP_TEST_DURATION = '10s'; /* THE DURATION FOR THE WARMUP RUN */
export const LOAD_TEST_START_TIME = '10s'; /* THE TIME TO WAIT AFTER WHICH THE LOAD TEST STARTS
                                              USUALLY THIS WOULD BE EQUAL TO WARMUP_TEST_DURATION */

export const options = {
scenarios:  {
    warmup: {
      executor: 'constant-vus',
      vus: WARMUP_TEST_VUS,
      duration: WARMUP_TEST_DURATION,
      gracefulStop: '0s',
      tags: { scenario: 'warmup' },
    },
    load_test: {
      executor: 'constant-vus',
      vus: LOAD_TEST_VUS,
      duration: LOAD_TEST_DURATION,
      startTime: LOAD_TEST_START_TIME,
      tags: { scenario: 'load_test' },
    },
  },
  thresholds: {
    'http_req_waiting{scenario:load_test}': [
      { threshold: `p(90)<${TTFB_THRESHOLD}`, abortOnFail: false }
    ],
    'http_reqs{scenario:load_test}': [
      { threshold: `rate>=${RPS_THRESHOLD}`, abortOnFail: false }
    ]
  },
};

export default function () {

  // WRITE THE TEST HERE

}

TTFB_THRESHOLD와 RPS_THRESHOLD에는 현재 보고에 사용되지 않으며 https://gitlab.com/gitlab-org/quality/component-performance-testing/-/issues/75의 일부로 제거될 예정이므로 현재 어떤 값이든 지정할 수 있습니다.

qa/performance_test/k6_test에 있는 다른 테스트를 참조하여 테스트를 작성할 수 있습니다.

테스트에 환경 데이터가 필요한 경우, mr_seed.rb 파일을 업데이트하여 생성해야 할 리소스를 추가할 수 있습니다.

mr_seed.rb에서 생성 중인 기존 리소스를 제거하지 마십시오.

Component Performance testing은 현재 여러 시드 파일을 지원하지 않지만, 이는 https://gitlab.com/gitlab-org/quality/component-performance-testing/-/issues/76의 일부로 해결될 예정입니다.

e2e:perf-on-cng 테스트 job 건너뛰기#

MR 파이프라인에서 e2e:perf-on-cng 테스트 job이 실행되지 않도록 하려면, 머지 리퀘스트 생성 시 pipeline:skip-performance 라벨을 추가하십시오.

트러블슈팅#

run-performance-test job 하위의 멀티 프로젝트 job이 gem 비호환성 오류로 인해 데이터 시딩 중에 실패하는 경우가 있습니다.

오류 예시는 다음과 같습니다:

/usr/lib/ruby/gems/3.3.0/gems/bundler-2.6.9/lib/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:225:in `resolve_conflict': Could not find compatible versions (Bundler::PubGrub::SolveFailure)
Because every version of gitlab-backup-cli depends on grpc ~> 1.74.0
  and Gemfile depends on gitlab-backup-cli >= 0,
  grpc ~> 1.74.0 is required.

이는 머지 리퀘스트에 포함되지 않은 Gemfile 업데이트가 있었을 수 있기 때문에 발생합니다. 머지 리퀘스트 브랜치를 master 브랜치로 리베이스하면 이 문제를 해결할 수 있습니다.

e2e:test-on-cng#

e2e:test-on-cng 하위 파이프라인은 Cloud Native GitLab 설치 환경에 대해 테스트를 실행합니다.

배포는 orchestrator CLI 도구로 관리되며, 이를 사용하여 CI/CD 배포를 로컬에서 재현할 수도 있습니다.

e2e:test-on-cng 하위 파이프라인은 머지 리퀘스트에서 실행되며 사전 병합 검증 라이프사이클의 일부입니다. 테스트가 실패하면 도입된 코드 변경 사항을 병합할 수 없습니다.

Setup#

이 E2E 테스트 하위 파이프라인은 e2e-test-pipeline-generate CI/CD job의 아티팩트로 저장된 동적으로 생성된 CI/CD YAML 파일을 사용하여 e2e:test-on-cng job에 의해 트리거됩니다. CI/CD YAML 파일은 템플릿을 사용하여 생성됩니다.

하위 파이프라인 job#

하위 파이프라인은 E2E 테스트 실행을 지원하는 여러 Stage로 구성됩니다.

.pre#

• build-cng-env job은 CNG 다운스트림 파이프라인을 위한 모든 환경 변수를 설정합니다.

• build-cng job은 필요한 모든 이미지를 빌드하는 CNG 다운스트림 파이프라인을 트리거합니다.

test#

test Stage의 job은 다음 작업을 수행합니다:

• kind를 사용한 로컬 k8s 클러스터 Setup

• 공식 helm 차트를 사용한 GitLab 설치

• 수행된 배포에 대한 E2E 테스트 실행

test Stage의 job:

• cng-instance는 오케스트레이션된 테스트를 제외한 전체 e2e 스위트를 CNG에 대해 실행합니다.

• cng-registry는 레지스트리 시나리오 Test::Integration::Registry의 테스트를 CNG에 대해 실행합니다.

• cng-relative-url은 CNG에 상대 URL이 설정된 상태에서 스모크 스위트 Test::Instance::Smoke를 실행합니다.

• cng-oauth는 OmniAuth가 활성화된 GitHub와 GitLab 간의 인증을 위한 e2e 스펙을 실행합니다.

report#

이 Stage는 allure 테스트 리포트 생성을 담당합니다.

디버깅#

디버깅을 돕기 위해:

• 각 테스트 job은 로컬 디버깅을 위해 동일한 배포를 정확히 재현하기 위해 orchestrator에 전달할 수 있는 인수 목록을 출력합니다.

• 클러스터 이벤트 로그와 모든 Pod 로그는 E2E 테스트 job 아티팩트에 저장됩니다.

• orchestrator는 배포 실패 시 오류가 있는 모든 클러스터 이벤트를 자동으로 출력합니다.

e2e:test-on-omnibus-ee#

e2e:test-on-omnibus-ee 하위 파이프라인은 Omnibus 설치 환경에 대해 테스트를 실행합니다. 이 파이프라인 유형은 기본적으로 머지 리퀘스트 파이프라인에서 실행되지 않으며, e2e:test-on-omnibus-ee job을 트리거하여 수동으로 실행할 수 있습니다.

이 파이프라인 유형은 실패가 허용되며, 머지 리퀘스트 파이프라인 내에서 수동으로 트리거하더라도 실패한 테스트는 병합 기능을 차단하지 않습니다.

Linux 패키지 배포는 gitlab-qa로 관리됩니다.

Setup#

이 E2E 테스트 하위 파이프라인은 e2e-test-pipeline-generate CI/CD job의 아티팩트로 저장된 동적으로 생성된 CI/CD YAML 파일을 사용하여 e2e:test-on-omnibus-ee job에 의해 트리거됩니다. CI/CD YAML 파일은 템플릿을 사용하여 생성됩니다.

하위 파이프라인 job#

E2E 테스트 실행 파이프라인은 E2E 테스트 실행을 모두 지원하는 여러 Stage로 구성됩니다.

.pre#

이 Stage는 다음 태스크를 담당합니다:

• omnibus-gitlab Docker 이미지를 빌드하는 다운스트림 파이프라인을 트리거합니다.

test#

test Stage의 job은 다음 작업을 수행합니다:

• 빌드된 Linux 패키지를 사용하여 GitLab을 설치합니다.

• Linux 패키지 설치에 대해 E2E 테스트를 실행합니다.

report#

이 Stage는 allure 테스트 리포트 생성을 담당합니다.

e2e:test-on-gdk#

e2e:test-on-gdk 하위 파이프라인은 e2e:test-on-omnibus-ee보다 빠르게 엔지니어에게 엔드투엔드 테스트 실행에 대한 피드백을 제공하여 GitLab 플랫폼 개발을 지원합니다.

이는 Omnibus GitLab에 대해 테스트할 때보다 더 짧은 시간에 빌드하고 설치할 수 있는 GitLab Development Kit(GDK)에 대해 테스트를 실행함으로써 달성됩니다. 트레이드오프는 Omnibus GitLab이 프로덕션 설치를 배포하는 데 사용될 수 있는 반면, GDK는 개발 환경이라는 점입니다. GDK에 대해 실행되는 테스트는 프로덕션 환경에서 GitLab을 실행하기 위한 준비 프로세스의 일부에 의존하는 버그, 예를 들어 에셋 사전 컴파일, 공식 설치 패키지의 일부로 구성 기본값 설정, 여러 서버에 GitLab 서비스 배포 등을 발견하지 못할 수 있습니다. 반면에 일상적으로 GDK를 사용하는 엔지니어는 GDK에서만 나타나는 버그를 발견하는 자동화된 테스트의 혜택을 받을 수 있습니다.

Setup#

이 E2E 테스트 하위 파이프라인은 e2e-test-pipeline-generate CI/CD job의 아티팩트로 저장된 동적으로 생성된 CI/CD YAML 파일을 사용하여 e2e:test-on-gdk job에 의해 트리거됩니다. CI/CD YAML 파일은 템플릿을 사용하여 생성됩니다.

build-gdk-image#

build-gdk-image job은 머지 리퀘스트의 코드를 사용하여 테스트 job에서 컨테이너에 GDK 인스턴스를 실행하는 데 사용할 수 있는 Docker 이미지를 빌드합니다. 이미지는 컨테이너 레지스트리에 푸시됩니다.

이 job은 또한 GDK와 GitLab 컴포넌트를 포함하는 기본 이미지를 빌드하기 위해 기본 브랜치의 파이프라인에서도 실행됩니다. 이를 통해 머지 리퀘스트에서 전체 이미지를 처음부터 빌드하는 것을 피할 수 있습니다. 그러나 머지 리퀘스트에 특정 GitLab 컴포넌트 또는 코드에 대한 변경 사항이 포함된 경우, 이 job은 테스트 job에서 사용될 이미지를 빌드하기 전에 기본 이미지를 다시 빌드합니다.

하위 파이프라인 job#

하위 파이프라인은 E2E 테스트 실행을 지원하는 여러 Stage로 구성됩니다.

test#

test Stage의 job은 다음 작업을 수행합니다:

• build-gdk-image job으로 빌드된 Docker 이미지를 사용하여 GDK 인스턴스를 시작합니다.

• 실행 중인 GDK 인스턴스에 대해 E2E 테스트를 실행합니다.

report#

이 Stage는 allure 테스트 리포트 생성을 담당합니다.

테스트 라이선스#

이 파이프라인에서 사용하는 라이선스에 대한 자세한 내용은 테스트 라이선스를 참조하십시오.

E2E 테스트 파이프라인에 새 job 추가#

E2E 테스트 파이프라인은 런타임에 따른 동적 job 스케일링을 사용합니다. 파이프라인 정의 YAML 파일의 job 정의와 특정 테스트 시나리오 간의 매핑을 생성하기 위해 scenario 클래스가 사용됩니다. 이 클래스는 qa/qa/scenario 폴더에 위치합니다.

e2e 테스트 파이프라인 정의 YAML 파일 중 하나의 일반적인 job 정의는 다음과 같습니다:

my-new-test-job:
  # ...
  variables:
    QA_SCENARIO: Test::Integration::MyNewTestScenario

이 예시에서:

• QA_SCENARIO: Test::Integration::MyNewTestScenario: qa/bin/qa 테스트 실행 스크립트에 전달되는 시나리오 클래스의 이름입니다. 전체 클래스 이름은 QA::Scenario::Test:Integration::MyNewTestScenario이지만, 더 짧은 정의를 위해 QA::Scenario는 생략됩니다.

위의 예시를 고려하여, 새 job을 생성하려면 다음 단계를 수행하십시오:

• e2e 테스트 프레임워크의 integration 디렉터리에 새 시나리오 my_new_job.rb를 생성합니다. 시나리오 클래스는 시나리오를 특정 파이프라인 유형의 특정 job과 연결하는 파이프라인 매핑을 정의해야 합니다. job이 test-on-cng 파이프라인에 추가된 경우, 이 시나리오는 실행해야 할 RSpec 태그와 파이프라인 매핑을 정의합니다:

module QA
  module Scenario
    module Test
      module Integration
        class MyNewJob < Test::Instance::All
          tags :some_special_tag

          pipeline_mappings test_on_cng: %w[my-new-test-job]
        end
      end
    end
  end
end

• main.gitlab-ci.yml 파이프라인 정의에 새 job 정의를 추가합니다:

my-new-test-job:
  extends:
    - .cng-test
  variables:
    QA_SCENARIO: Test::Integration::MyNewTestScenario

이러한 정의는 my-new-test-job이 미리 정의된 런타임 임계값을 기반으로 자동 병렬 job 스케일링을 갖도록 보장합니다.