엔드투엔드 테스트 파이프라인

e2e:package-and-test 하위 파이프라인

e2e:package-and-test 하위 파이프라인은 GitLab 플랫폼의 엔드투엔드 테스트의 주요 실행자입니다. 파이프라인 정의에는 실행 중인 Merge Request 파이프라인에서 실행되는 테스트의 수를 줄이기 위한 여러 동적 컴포넌트가 있습니다.

설정

파이프라인 설정은 다음으로 구성됩니다.

  • 주요 GitLab 파이프라인의 prepare 단계에 있는 e2e-test-pipeline-generate 작업.
  • qa 단계에 있는 e2e:package-and-test 작업은 omnibus 패키지 빌드와 E2E 테스트 실행을 담당하는 하위 파이프라인을 트리거합니다.

e2e-test-pipeline-generate

이 작업에는 선택적 테스트 실행을 구현하는 두 가지 컴포넌트가 있습니다.

  • detect_changes Rake 태스크는 특정 Merge Request 파이프라인에서 실행해야 하는 e2e 스펙을 결정합니다. 이 태스크는 특정 Merge Request의 변경 사항을 분석하고 실행해야 하는 스펙을 결정합니다. 이를 바탕으로 각 시나리오의 dry-run이 실행되어 시나리오가 실행 가능한 테스트를 포함하는지 여부를 결정합니다. 선택적 테스트 실행은 특정 테스트를 실행하기 위해 다음 기준을 사용합니다.
  • generate-e2e-pipeline이 실행되어 적절한 환경 변수로 하위 파이프라인 YAML 정의 파일을 생성합니다.

e2e:package-and-test 실행 파이프라인

E2E 테스트 실행 파이프라인에는 모든 E2E 테스트의 실행을 지원하는 여러 단계가 포함되어 있습니다.

.pre

이 단계는 다음 작업을 담당합니다.

  • 병렬 테스트 실행을 지원하는 knapsack 보고서 검색.
  • omnibus-gitlab 도커 이미지를 빌드하는 하위 파이프라인을 트리거합니다.
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 실행기에 전달되는 시나리오 클래스의 이름.
  • !reference [.rules:test:qa, rules]: 모든 테스트를 실행해야 하는 파이프라인에 일치하는 주요 규칙 정의. 예를 들어, qa 프레임워크에 변경 사항이 있는 경우.

  • if: $QA_SUITES =~ /Test::Integration::MyNewJob/: 선택적 테스트 실행을 담당하는 주요 규칙. QA_SUITE는 qa framework에 위치한 시나리오 추상화의 이름입니다.

    QA_SUITE는 gitlab-qa 실행기에 전달되는 QA_SCENARIO와는 다르며, 일관성을 위해 일반적으로 동일한 이름을 가집니다. QA_SUITE 추상화 클래스에는 일반적으로 실행할 태그 및 선택적으로 추가 설정 단계에 대한 정보가 포함되어 있습니다.

  • !reference [.rules:test:manual, rules]: 항상 일치하고 작업을 manual로 설정하여 선택적 테스트 실행에 따라 실행되지 않더라도 필요에 따라 실행할 수 있는 최종 규칙.

위 예제를 고려하여 새로운 작업을 만들려면 다음 단계를 수행하세요.

  1. gitlab-qa 프로젝트의 integration 디렉터리에 my_new_job.rb와 같은 새로운 시나리오 유형을 만들고 일반적으로 사용할 수 있도록 새 버전을 릴리스합니다.

  2. 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

  3. 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 하위 파이프라인은 엔지니어들에게 e2e:package-and-test나 리뷰 앱을 통해보다 빠르게 엔드투엔드 테스트 실행에 대한 피드백을 제공하여 GitLab 플랫폼의 개발을 지원합니다.

이는 GitLab Development Kit(GDK)에 대한 테스트를 실행하여 단시간에 빌드하고 설치할 수 있으므로 Omnibus GitLab에 대한 테스트보다 빠르게 엔드투엔드 테스트 실행 피드백을 제공하는 것으로 달성됩니다. 단점으로는 Omnibus GitLab은 프로덕션 설치에 사용될 수 있지만 GDK는 개발 환경임. GDK에서 실행되는 테스트는 프로덕션 환경에서 GitLab의 준비 프로세스 일부에 따라 오류를 포착하지 못할 수 있습니다. 이는 공식 설치 패키지의 구성 기본값을 할당하고 GitLab 서비스를 여러 서버에 배포하는 등 GitLab을 프로덕션 환경에서 실행하기 위한 일부 과정에 의존하는 버그를 잡아내지 못할 수 있습니다. 반면에 GDK를 일상적으로 사용하는 엔지니어들은 GDK에서만 나타나는 버그를 자동화된 테스트로 잡아낼 수 있습니다.

설정

파이프라인 설정은 기본 GitLab 파이프라인에서 여러 작업으로 구성됩니다:

  • prepare 단계의 e2e-test-pipeline-generate 작업. 이 작업은 e2e:package-and-test 파이프라인과 동일합니다.
  • build-images 단계의 build-gdk-image 작업.
  • qa 단계의 e2e:test-on-gdk 트리거 작업은 E2E 테스트를 실행하는 하위 파이프라인을 트리거합니다.

build-gdk-image

이 작업 은 Merge Request에서 코드를 사용하여 테스트 작업에서 GDK 인스턴스를 실행하기 위한 도커 이미지를 빌드합니다. 이미지는 컨테이너 레지스트리에 푸시됩니다.

이 작업은 또한 기본 브랜치의 파이프라인에서 GDK와 GitLab 컴포넌트가 포함된 기본 이미지를 빌드합니다. 이는 Merge Request에서 처음부터 전체 이미지를 빌드하는 것을 피합니다. 그러나 Merge Request이 특정 GitLab 컴포넌트나 코드 에 변경 사항을 포함하는 경우, 작업은 테스트 작업에 사용될 이미지를 빌드하기 전에 기본 이미지를 다시 빌드할 것입니다.

e2e:test-on-gdk 하위 파이프라인

e2e:package-and-test 파이프라인과 마찬가지로, e2e:test-on-gdk 파이프라인은 E2E 테스트를 지원하는 여러 단계로 구성됩니다.

.pre

이 단계는 병렬 테스트 실행을 지원하는 knapsack 보고서를 가져오는 것을 담당합니다.

test

이 단계는 다양한 유형의 GitLab 구성에 대해 e2e 테스트를 실행합니다. 실행되는 작업 수는 e2e-test-pipeline-generate 작업에 의해 동적으로 결정됩니다.

각 작업은 build-gdk-image 작업에서 생성된 GDK 도커 이미지에서 컨테이너를 시작하고, 컨테이너에서 실행중인 GDK 인스턴스에 대해 종단 간 테스트를 실행합니다.

report

이 단계는 allure 테스트 보고서 생성을 담당합니다.

e2e:test-on-cng

e2e:test-on-cng 하위 파이프라인은 Cloud Native GitLab 설치에 대한 테스트를 실행합니다. review-apps와 달리, 이 파이프라인은 로컬 kind Kubernetes 클러스터를 사용합니다.

현재 이 파이프라인은 매일 예약된 파이프라인에서 실행되며 주로 redis의 최소 지원 버전과의 호환성을 테스트합니다.

설정

파이프라인 설정은 기본 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 차트를 사용하여 GitLab 설치
  • 수행된 배포에 대한 E2E 테스트 실행

report

이 단계는 allure 테스트 보고서 생성 및 테스트 메트릭 업로드를 담당합니다.