• 파이프라인 계층
• 병합 요청 승인 전 예측 테스트 작업
  • GitLab 프로젝트 테스트 종속성 개요
  • 예측 테스트 대시보드
  • detect-tests CI 작업
  • RSpec 예측 작업
    • 병합 요청에서 예측 RSpec 테스트 파일 결정
      • 동적 매핑
      • 정적 매핑
    • 예외적 사례
    • 백엔드 예측 테스트에 문제가 발생했습니까?
  • Jest 예측 작업
    • 병합 요청에서 예측 Jest 테스트 파일 결정하기
    • 예외적 사례
    • 프론트엔드 예측 테스트에 문제가 발생한 적이 있습니까?
  • 포크 파이프라인
• 머지 요청 파이프라인의 Fail-fast 작업
• 머지 요청 파이프라인에서 이전에 실패한 테스트 재실행
  • 작동 방식
• 병합 기차
  • 현재 사용 현황
  • 다음 진행 사항
  • “전체” 테스트 파이프라인을 실행하는 병합 기차 활성화의 과제
    • 왜 “안정적인” 기본 브랜치가 필요합니까?
    • 기본 브랜치는 얼마나 안정적이어야 합니까?
• 일부 병합 요청에 대한 빠른 피드백
  • 손상된 master 수정
  • 되돌리기 MRs
  • pipeline::expedited 레이블
• 테스트 작업
  • 엔드 투 엔드 작업
  • 옵저버빌리티 엔드 투 엔드 작업
  • 리뷰 앱 작업
  • As-if-FOSS 작업 및 크로스 프로젝트 다운스트림 파이프라인
    • 프로젝트 변수에 설정된 토큰
  • As-if-JH 크로스 프로젝트 다운스트림 파이프라인
    • 정의
    • 실행 방법
    • pipeline:run-as-if-jh 레이블 적용 시 고려사항
    • 해당 JH 브랜치
    • as-if-JH 파이프라인 구성 방법
      • 프로젝트 변수에 설정된 토큰
      • as-if-JH 브랜치를 생성하는 방법
      • as-if-JH 파이프라인을 트리거하고 실행하는 방법
      • GitLab JH 미러 프로젝트 설정 방법
      • GitLab JH 검증 프로젝트 설정 방법
      • 우리는 왜 미러 프로젝트와 검증 프로젝트를 모두 가지고 있나요?
  • rspec:undercoverage 작업
    • rspec:undercoverage 실패 문제 해결
  • pajamas_adoption 작업
• 테스트 스위트 병렬화
• 흔들리는 테스트
  • 흔들리는 테스트의 자동 스킵
  • 별도의 프로세스에서 실패한 테스트의 자동 재시도
• 호환성 테스트
  • 루비 버전 테스트
  • PostgreSQL 버전 테스트
    • 현재 버전 테스트
  • Redis 버전 테스트
    • 현재 버전 테스트
  • 단일 데이터베이스 테스트
• 모니터링
• 로깅
• 병합 요청을 위한 파이프라인 유형
  • 문서 파이프라인
  • 백엔드 파이프라인
  • 리뷰 앱 파이프라인
  • 엔드 투 엔드 파이프라인
• CI 구성 내부
• 성능

GitLab 프로젝트의 파이프라인

gitlab-org/gitlab (및 dev 인스턴스)의 파이프라인은 일반적으로 .gitlab-ci.yml에서 구성되어 있으며, 이는 보다 쉬운 유지 보수를 위해 .gitlab/ci/ 아래의 파일을 포함합니다.

우리는 가능하면 GitLab CI/CD 기능 및 모범 사례를 dogfood하려고 노력하고 있습니다.

gitlab-org/gitlab 파이프라인에서 CI/CD 구성 요소를 사용하지 마세요 dev.gitlab.com 인스턴스에 미러링된 경우를 제외하고. CI/CD 구성 요소는 다른 인스턴스 간에 작동하지 않으며, 그 인스턴스에 존재하지 않을 경우 파이프라인 실패를 유발합니다.

파이프라인 계층

현재 활발히 개발 중: 더 많은 정보는 epic 58를 참고하세요.

병합 요청은 일반적으로 여러 CI/CD 파이프라인을 실행합니다. 병합 요청의 승인 프로세스에 따른 위치에 따라, 우리는 다양한 종류의 파이프라인을 트리거합니다. 이러한 종류의 파이프라인을 우리는 파이프라인 계층이라고 부릅니다.

현재 우리는 세 가지 계층이 있습니다:

1. pipeline::tier-1: 병합 요청에 승인 없음
2. pipeline::tier-2: 병합 요청에 최소 하나의 승인 있지만, 추가 승인이 필요함
3. pipeline::tier-3: 병합 요청에 필요한 모든 승인을 보유함

일반적으로 낮은 파이프라인 계층일수록 파이프라인은 더 빨라야 합니다.

높은 파이프라인 계층일수록 더 많은 테스트를 실행하여 더 많은 신뢰를 제공해야 합니다.

구현에 대한 자세한 정보는 MR 파이프라인에서 “tiers” 도입하기 에픽을 참조하세요.

병합 요청 승인 전 예측 테스트 작업

파이프라인 비용을 줄이고 작업 기간을 단축시키기 위해, 병합 요청이 승인되기 전 파이프라인은 병합 요청 변경 사항에 대해 실패할 가능성이 높은 예측된 RSpec 및 Jest 테스트 세트를 실행합니다.

병합 요청이 승인된 후 파이프라인은 전체 RSpec 및 Jest 테스트를 포함합니다. 이는 병합 요청이 병합되기 전에 모든 테스트가 실행되었음을 보장합니다.

GitLab 프로젝트 테스트 종속성 개요

예측 테스트 작업이 어떻게 실행되는지 이해하기 위해, 우리는 GitLab 코드(프론트엔드 및 백엔드)와 해당 테스트(Jest 및 RSpec) 간의 종속성을 이해해야 합니다.

이 종속성은 다음 다이어그램에서 시각화할 수 있습니다:

요약:

• RSpec 테스트는 백엔드 코드에 종속적입니다.
• Jest 테스트는 프론트엔드 및 백엔드 코드에 모두 종속적이며, 후자는 프론트엔드 픽스처를 통해 연결됩니다.

예측 테스트 대시보드

• https://10az.online.tableau.com/#/site/gitlab/views/DRAFTTestIntelligenceAccuracy/TestIntelligenceAccuracy

detect-tests CI 작업

gitlab-org/gitlab의 대부분 CI/CD 파이프라인은 주어진 MR에서 변경된 파일을 기준으로 어떤 백엔드/프론트엔드 테스트를 실행해야 하는지 감지하기 위해 prepare 단계에서 detect-tests CI 작업을 실행합니다.

detect-tests 작업은 실행해야 할 백엔드/프론트엔드 테스트를 포함하는 많은 파일을 생성합니다. 이 파일들은 파이프라인의 후속 작업에서 읽히며, 오로지 해당 테스트만 실행됩니다.

RSpec 예측 작업

병합 요청에서 예측 RSpec 테스트 파일 결정

병합 요청에서 실패할 가능성이 있는 RSpec 테스트를 식별하기 위해 동적 매핑과 정적 매핑을 사용합니다.

동적 매핑

우선, 우리는 test_file_finder gem과 함께, Crystalball gem에서 제공하는 동적 매핑 전략을 사용합니다)

(어디에 사용되는지 보기, 그리고 Crystalball에서 사용하는 매핑 전략).

test_file_finder에 추가하여, 정말 더 많은 테스트를 실행하기 위해 여러 가지 고급 매핑 전략을 추가했습니다:

• FindChanges (!74003)
  • 백엔드 변경이 있을 때 실행할 Jest 테스트를 자동으로 감지합니다 (프론트엔드 픽스를 통해).
• PartialToViewsMappings (#395016)
  • Rails 부분이 포함된 뷰에서 변경 사항이 생기면 뷰 사양을 실행합니다.
• JsToSystemSpecsMappings (#386754)
  • MR에서 JavaScript 파일이 변경되면 특정 시스템 사양을 실행합니다.
• GraphqlBaseTypeMappings (#386756)
  • GraphQL 타입 클래스가 변경되면, 이 타입을 포함할 가능성이 있는 다른 GraphQL 타입을 식별하고 그들의 사양을 실행해야 합니다.
• ViewToSystemSpecsMappings (#395017)
  • 뷰가 변경되면 해당 코드 영역을 테스트할 기능 사양을 찾아보려고 합니다.
• ViewToJsMappings (#386719)
  • JS 파일이 변경되면, 이 JS 구성 요소를 다루는 시스템 사양을 식별하려고 합니다.
• FindFilesUsingFeatureFlags (#407366)
  • 기능 플래그가 변경되면, 어떤 Ruby 파일이 해당 기능 플래그를 포함하고 있는지를 확인하고, 이를 detect-tests CI 작업에서 변경된 파일 목록에 추가합니다. 이후 작업에서는 이러한 변경된 파일을 기반으로 어떤 프론트엔드/백엔드 테스트가 실행되어야 하는지를 감지합니다.

정적 매핑

우리는 test_file_finder gem을 사용하며, 동적 매핑을 통해 매핑할 수 없는 특별한 경우를 위해 tests.yml 파일에서 정적 매핑을 유지합니다.

test mappings는 각 소스 파일에 대해 소스 파일에 의존하는 테스트 파일 목록의 매핑을 포함합니다.

예외적 사례

또한, 전체 RSpec 테스트를 항상 실행하는 몇 가지 상황이 있습니다:

• pipeline:run-all-rspec 레이블이 병합 요청에 설정된 경우. 이 레이블은 as-if-foss 작업에서 실행된 테스트를 포함하여 모든 RSpec 테스트를 트리거합니다.
• pipeline:mr-approved 레이블이 병합 요청에 설정되고 코드 변경 사항이 backend-patterns 규칙을 만족하는 경우. 이 레이블은 병합 요청이 리뷰어에 의해 승인될 때 triage automation에 의해 할당됩니다. 이 레이블을 수동으로 적용하는 것은 권장되지 않습니다.
• 자동화에 의해 병합 요청이 생성되는 경우(예: Gitaly 업데이트 또는 안정적인 브랜치를 타겟으로 하는 MR)
• 보안 미러에서 병합 요청이 생성되는 경우
• 모든 CI 구성 파일이 변경된 경우(예: .gitlab-ci.yml 또는 .gitlab/ci/**/*)

백엔드 예측 테스트에 문제가 발생했습니까?

그렇다면, 예측 테스트에 대한 엔지니어링 생산성 RUNBOOK을 확인하여 예측 테스트 문제에 대응하는 방법을 확인하세요. 또한, 테스트 선택의 격차를 발견한 경우, 최적의 테스트 선택을 위해 필요한 조치를 취할 수 있도록 @gl-quality/eng-prod에 알려주십시오.

Jest 예측 작업

병합 요청에서 예측 Jest 테스트 파일 결정하기

병합 요청에서 실패할 가능성이 있는 jest 테스트를 식별하기 위해 변경된 모든 파일 목록을 jest에 --findRelatedTests 옵션과 함께 전달합니다.

이 모드에서 jest는 변경된 파일과 관련된 모든 종속성을 해결하며, 여기에는 이러한 파일이 종속성 체인에 있는 테스트 파일이 포함됩니다.

예외적 사례

또한, 전체 Jest 테스트를 항상 실행하는 몇 가지 상황이 있습니다:

• pipeline:run-all-jest 레이블이 병합 요청에 설정된 경우
• 자동화에 의해 병합 요청이 생성되는 경우(예: Gitaly 업데이트 또는 안정적인 브랜치를 타겟으로 하는 MR)
• 보안 미러에서 병합 요청이 생성되는 경우
• 관련 CI 구성 파일이 변경된 경우(.gitlab/ci/rules.gitlab-ci.yml, .gitlab/ci/frontend.gitlab-ci.yml)
• 모든 프론트엔드 종속성 파일이 변경된 경우(예: package.json, yarn.lock, config/webpack.config.js, config/helpers/**/*.js)
• 모든 공급된 JavaScript 파일이 변경된 경우(예: vendor/assets/javascripts/**/*)

전체 Jest 테스트에 대한 rules 정의는 rules.gitlab-ci.yml의 .frontend:rules:jest에 정의되어 있습니다.

프론트엔드 예측 테스트에 문제가 발생한 적이 있습니까?

그렇다면 예측 테스트에 대한 엔지니어링 생산성 RUNBOOK에서 예측 테스트 문제에 대한 조치 방법을 확인하세요.

포크 파이프라인

포크 파이프라인에서는 pipeline:run-all-rspec 레이블이 MR에 설정되지 않는 한, 예측 RSpec 및 Jest 작업만 실행합니다.

목표는 포크 파이프라인에서 소비되는 컴퓨트 쿼터를 줄이는 것입니다.

실험 이슈를 참조하세요.

머지 요청 파이프라인의 Fail-fast 작업

머지 요청이 기존 테스트를 깨뜨릴 때 더 빠른 피드백을 제공하기 위해, 우리는 Fail-fast 메커니즘을 구현했습니다.

rspec fail-fast 작업이 머지 요청 파이프라인의 모든 다른 rspec 작업과 병렬로 추가됩니다.

이 작업은 머지 요청의 변경 사항과 직접적으로 관련된 테스트를 실행합니다.

이 테스트 중 하나라도 실패하면, rspec fail-fast 작업이 실패하고, fail-pipeline-early 작업이 실행되도록 트리거됩니다.

fail-pipeline-early 작업은 다음과 같은 작업을 수행합니다:

• 현재 실행 중인 파이프라인과 모든 진행 중인 작업을 취소합니다.
• 파이프라인의 상태를 failed로 설정합니다.

예를 들어:

rspec fail-fast는 머지 요청과 관련된 테스트 파일이 10개를 초과하면 작동하지 않습니다.

이는 rspec fail-fast의 지속 시간이 평균 rspec 작업 지속 시간을 초과하는 것을 방지하여 그 목적을 무효화합니다.

이 숫자는 RSPEC_FAIL_FAST_TEST_FILE_COUNT_THRESHOLD라는 CI/CD 변수를 설정하여 재정의할 수 있습니다.

머지 요청 파이프라인에서 이전에 실패한 테스트 재실행

머지 요청에 대한 실패한 테스트를 해결한 후 피드백 시간을 줄이기 위해, rspec rspec-pg14-rerun-previous-failed-tests 및 rspec rspec-ee-pg14-rerun-previous-failed-tests 작업이 이전 MR 파이프라인의 실패한 테스트를 실행합니다.

이는 2021년 8월 25일에 도입되었으며, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69053를 참조하세요.

작동 방식

1. detect-previous-failed-tests 작업(prepare 단계)은 이전 MR 파이프라인의 실패한 RSpec 작업과 관련된 테스트 파일을 감지합니다.

2. rspec rspec-pg14-rerun-previous-failed-tests 및 rspec rspec-ee-pg14-rerun-previous-failed-tests 작업은 detect-previous-failed-tests 작업에서 수집한 테스트 파일을 실행합니다.

병합 기차

현재 사용 현황

우리는 2024년 6월에 병합 기차를 사용하기 시작했습니다..

현재 병합 기차 파이프라인은 테스트를 실행하지 않습니다: 그들은 병합 기차의 활성화 이전에 이미 존재했던 “병합 요청 병합” 가이드라인을 시행할 뿐이며, 우리는 이를 쉽게 시행할 수 없었습니다.

병합 기차 파이프라인은 단일 pre-merge-checks 작업을 실행하며, 병합 전에 최신 파이프라인이 다음과 같음을 보장합니다:

1. 병합된 결과 파이프라인
2. tier-3 파이프라인 (즉, 전체 파이프라인, 예측적이지 않은 파이프라인)
3. 최대 8시간 전에 생성됨 (안정적인 브랜치의 경우 72시간)

우리는 피드백 이슈를 열었습니다. 이 솔루션에 대해 반복하기 위해.

다음 진행 사항

우리는 병합 기차의 다음 진행 사항에 대해 논의할 전용 이슈를 열었습니다. 실제로 병합 기차 파이프라인에서 테스트를 실행하기 시작하기 위해.

“전체” 테스트 파이프라인을 실행하는 병합 기차 활성화의 과제

왜 “안정적인” 기본 브랜치가 필요합니까?

기본 브랜치가 불안정한 경우(즉, 기본 브랜치의 CI/CD 파이프라인이 자주 실패하는 경우), 결함이 있는 병합 요청 파이프라인 이후에 추가된 모든 병합 요청 파이프라인은 취소되고 기차에 다시 추가되어야 하므로, 병합 기차가 길 경우 지연이 매우 발생하게 됩니다.

기본 브랜치는 얼마나 안정적이어야 합니까?

특정 수치는 없지만, 우리는 변동성이 높은 테스트 실패와 인프라 실패에 대한 더 나은 수치가 필요합니다 (자세한 내용은 마스터 손상 사건 RCA 대시보드를 참조하십시오).

일부 병합 요청에 대한 빠른 피드백

손상된 master 수정

손상된 master를 수정해야 할 때, 병합 요청에서 실행되는 파이프라인을 신속하게 처리하기 위해 pipeline::expedited 레이블을 추가할 수 있습니다.

병합 요청에도 master:broken 또는 master:foss-broken 레이블이 설정되어야 합니다.

되돌리기 MRs

당신의 되돌리기 MRs를 더 빠르게 만들기 위해, 병합 요청을 생성하기 전에 되돌리기 MR 템플릿을 사용하십시오. 이는 pipeline::expedited 레이블과 병합 요청에서 실행되는 파이프라인을 신속하게 처리하는 여러 레이블을 적용합니다.

pipeline::expedited 레이블

이 레이블이 할당되면 CI/CD 파이프라인의 다음 단계가 생략됩니다:

• e2e:test-on-omnibus 작업.
• rspec:undercoverage 작업.
• 전체 리뷰 앱 프로세스.

레이블을 병합 요청에 적용하고, MR에 대한 새 파이프라인을 실행하십시오.

테스트 작업

각 테스트 레벨에 대한 전용 작업이 있으며, 각 작업은 병합 요청에서 변경된 내용에 따라 실행됩니다.

모든 RSpec 작업을 강제로 실행하고 싶다면, 병합 요청에 pipeline:run-all-rspec 레이블을 추가할 수 있습니다.

경고:
문서와 관련된 MRs에서 모든 작업을 강제로 실행하면 필수 작업이 없고 오류가 발생할 수 있습니다.

엔드 투 엔드 작업

e2e:test-on-omnibus 자식 파이프라인은 변경 사항에 따라 자동으로 엔드 투 엔드 작업을 실행하며, 다른 경우에는 수동입니다.

특정 규칙 목록은 rules.gitlab-ci.yml에서 .qa:rules:test-on-omnibus를 참조하세요.

변경 사항에 관계없이 e2e:test-on-omnibus를 강제로 실행하려면, 병합 요청에 pipeline:run-all-e2e 레이블을 추가할 수 있습니다.

e2e:test-on-gdk 자식 파이프라인은 모든 code patterns changes에 대해 :blocking E2E 사양을 자동으로 실행합니다.

특정 규칙 세트는 rules.gitlab-ci.yml에서 .qa:rules:e2e-blocking-gdk를 참조하세요.

자세한 정보는 엔드 투 엔드 테스트 전용 페이지를 참조하세요.

옵저버빌리티 엔드 투 엔드 작업

GitLab Observability Backend에는 GitLab 인스턴스를 대상으로 실행되는 전용 엔드 투 엔드 테스트가 있습니다.

이 테스트는 GitLab과 Observability Backend 간의 통합이 올바르게 작동하는지 확인하도록 설계되었습니다.

GitLab 파이프라인에는 GitLab MR에서 실행할 수 있는 전용 작업이 있습니다 (see observability-backend.gitlab-ci.yml). 이 작업은 GitLab MR 브랜치에서 빌드된 GitLab 인스턴스에 대해 GitLab Observability Backend 파이프라인에서 E2E 테스트를 트리거합니다.

이 작업은 검토 중인 GitLab 변경 사항이 GitLab Observability Backend 파이프라인의 E2E 테스트를 깨지 않도록 하는 데 유용합니다.

옵저버빌리티 엔드 투 엔드 작업은 두 개가 있습니다:

• e2e:observability-backend-main-branch: GitLab Observability Backend의 주요 브랜치를 대상으로 테스트를 실행합니다.
• e2e:observability-backend: MR 브랜치와 동일한 이름을 가진 GitLab Observability Backend의 브랜치를 대상으로 테스트를 실행합니다.

옵저버빌리티 E2E 작업은 lib/gitlab/observability/ 디렉터리의 파일이나 옵저버빌리티 기능과 관련된 특정 구성 파일을 변경하는 병합 요청에 대해 자동으로 트리거됩니다.

이러한 작업을 수동으로 실행하려면 병합 요청에 pipeline:run-observability-e2e-tests-main-branch 또는 pipeline:run-observability-e2e-tests-current-branch 레이블을 추가할 수 있습니다.

다음은 옵저버빌리티 코드에 변화를 주고 옵저버빌리티 엔드 투 엔드 작업을 사용하는 개발자의 예시 워크플로우입니다:

1. 개발자는 옵저버빌리티 코드를 수정하는 GitLab MR을 생성합니다. MR은 자동으로 e2e:observability-backend-main-branch 작업을 실행합니다.

2. e2e:observability-backend-main-branch가 실패하면, 이는 MR이 무언가를 깨뜨렸거나 (수정이 필요함) MR이 E2E 테스트 업데이트가 필요한 변경을 했음을 의미합니다.

3. E2E 테스트를 업데이트하려면, 개발자는 다음을 수행해야 합니다:

   1. GitLab Observability Backend 저장소에서 동일한 이름의 브랜치를 생성합니다.

   2. E2E 테스트를 수정합니다.

   3. 변경사항으로 병합 요청을 생성합니다.

4. 개발자는 GitLab MR에 pipeline:run-observability-e2e-tests-current-branch 레이블을 추가하고 e2e:observability-backend 작업이 성공할 때까지 기다립니다.

5. e2e:observability-backend가 성공하면, 개발자는 두 개의 MR을 병합할 수 있습니다.

+추가로, 개발자는 MR이 옵저버빌리티와 관련하여 트래킹되지 않은 파일에 변경이 있을 때 e2e:observability-backend-main-branch 작업이 실행되도록 강제로 MR에 pipeline:run-observability-e2e-tests-main-branch를 수동으로 추가할 수 있습니다.

리뷰 앱 작업

start-review-app-pipeline 자식 파이프라인은 Review App를 배포하고 변경 사항에 따라 자동으로 엔드 투 엔드 테스트를 실행하며, 다른 경우에는 수동으로 실행됩니다.
자세한 규칙 목록은 rules.gitlab-ci.yml의
.review:rules:start-review-app-pipeline을 참조하세요.

변경 사항에 관계없이 Review App이 배포되도록 강제로 설정하려면,
풀 리퀘스트에 pipeline:run-review-app 레이블을 추가할 수 있습니다.

자세한 정보는 리뷰 앱 전용 페이지를 참조하세요.

As-if-FOSS 작업 및 크로스 프로젝트 다운스트림 파이프라인

해당 변경 사항이 FOSS 프로젝트에서 제대로 작동하는지 확인하기 위해,
일부 조건에서 다음을 실행합니다:

• 같은 파이프라인에서 * as-if-foss 작업
• 크로스 프로젝트 다운스트림 FOSS 파이프라인

* as-if-foss 작업은 GitLab 테스트 스위트를 “FOSS처럼” 실행하며,
즉, 작업이 gitlab-org/gitlab-foss의 맥락에서 실행되는 것처럼 의미합니다. 반면,
크로스 프로젝트 다운스트림 FOSS 파이프라인은 실제로 FOSS 프로젝트 내에서 실행되어,
더 실제 FOSS 환경에 가까워집니다.

다음 경우에 실행됩니다:

• 풀 리퀘스트에 pipeline:run-as-if-foss 레이블이 설정되었을 때
• gitlab-org/security/gitlab 프로젝트에서 풀 리퀘스트가 생성되었을 때
• CI 구성 파일이 변경되었을 때 (예: .gitlab-ci.yml 또는 .gitlab/ci/**/*)

* as-if-foss 작업은 일반 EE 맥락 작업에 추가로 실행됩니다.
이들은 FOSS_ONLY='1' 변수가 설정되어 있으며, 테스트가 시작되기 전에 ee/ 폴더가 제거됩니다.

크로스 프로젝트 다운스트림 FOSS 파이프라인은 풀 리퀘스트를 FOSS 프로젝트의 기본 브랜치에 병합하는 것을 시뮬레이션하며,
이로 인해 파일 목록이 제거됩니다. 목록은
.gitlab/ci/as-if-foss.gitlab-ci.yml
와
merge-train/bin/merge-train에서 확인할 수 있습니다.

목표는 변경 사항이 gitlab-org/gitlab가 gitlab-org/gitlab-foss와 동기화된 후에
실패를 초래하지 않도록 하는 것입니다.

프로젝트 변수에 설정된 토큰

• AS_IF_FOSS_TOKEN: 이는 GitLab FOSS
  프로젝트 토큰으로, developer 역할과 write_repository 권한을 가지고 있으며,
  생성된 as-if-foss/* 브랜치를 푸시하는 데 사용됩니다.
  • 같은 이름을 가진 보안 프로젝트는 보안 FOSS 프로젝트의 다른 토큰을 사용해야 하므로,
    공개 프로젝트에 보안 변경 사항을 푸시하지 않도록 합니다.

As-if-JH 크로스 프로젝트 다운스트림 파이프라인

정의

이 파이프라인은 JiHu 유효성 검사 파이프라인이라고도 불리며, 현재 실패가 허용됩니다. 그럴 경우, 따라야 할 것은 유효성 검사 파이프라인이 실패할 때 할 일입니다.

실행 방법

start-as-if-jh 작업은 GitLab 테스트 스위트를 “JiHu처럼” 실행하는 크로스 프로젝트 다운스트림 파이프라인을 트리거합니다. 이것은 파이프라인이 GitLab JH의 문맥에서 실행되는 것처럼 의미합니다. 이러한 작업은 다음 경우에만 생성됩니다:

• 기능 플래그에 변경이 있을 때
• 병합 요청에 pipeline:run-as-if-jh 레이블이 설정될 때

이 파이프라인은 GitLab JH 검증 프로젝트의 생성된 브랜치 문맥에서 실행되며, 이는 GitLab JH 미러의 미러입니다.

생성된 브랜치 이름은 병합 요청의 브랜치 이름과 함께 as-if-jh/로 접두사가 붙습니다. 이 생성된 브랜치는 병합 요청 브랜치를 기반으로 하며, 상단에 해당 JH 브랜치에서 다운로드한 변경 사항을 추가하여 전체 파이프라인을 JiHu처럼 만듭니다.

목적은 변경 사항이 GitLab이 GitLab JH과 동기화된 이후에 실패를 유발하지 않도록 하는 것입니다.

pipeline:run-as-if-jh 레이블 적용 시 고려사항

만약 Ruby 파일의 이름이 변경되고 해당 prepend_mod 줄이 존재하면, GitLab JH가 이를 의존하고 있을 가능성이 높으며, prepending 되고 있는 모듈이나 클래스의 이름을 변경하는 대응 조치가 필요합니다.

해당 JH 브랜치

브랜치 이름에 -jh를 추가하여 GitLab JH에서 해당 JH 브랜치를 생성할 수 있습니다. 해당 JH 브랜치가 발견되면, as-if-jh 파이프라인은 기본 브랜치 main-jh가 아닌 해당 브랜치에서 파일을 가져옵니다.

주목: 현재 CI는 GitLab JH 미러에서 브랜치를 가져오려고 하므로, 새로운 JH 브랜치가 미러로 전파되는 데 시간이 걸릴 수 있습니다.

주목: GitLab JH 검증은 GitLab JH 미러의 미러이지만, 기본 main-jh 외의 해당 JH 브랜치를 포함하지 않습니다.

따라서 해당 JH 브랜치를 가져오려면 검증 프로젝트가 아닌 기본 미러에서 가져와야 합니다.

as-if-JH 파이프라인 구성 방법

전체 프로세스는 다음과 같습니다:

프로젝트 변수에 설정된 토큰

• ADD_JH_FILES_TOKEN: 이는 GitLab JH mirror 프로젝트 토큰으로 read_api 권한을 가지고 있으며, JiHu 파일을 다운로드할 수 있습니다.

• AS_IF_JH_TOKEN: 이는 GitLab JH validation 프로젝트 토큰으로 developer 역할과 write_repository 권한을 가지고 있어, 생성된 as-if-jh/* 브랜치를 푸시할 수 있습니다.

as-if-JH 브랜치를 생성하는 방법

먼저 add-jh-files 작업이 해당 JH 브랜치에서 필요한 JiHu 파일을 다운로드하고 이를 아티팩트에 저장합니다. 다음으로 prepare-as-if-jh-branch 작업이 머지 요청 브랜치에서 새로운 브랜치를 생성하고, 변경 사항을 커밋한 후, 브랜치를 검증 프로젝트에 푸시합니다.

선택적으로, 머지 요청에 의존성에 대한 변경 사항이 있는 경우, sync-as-if-jh-branch 작업을 실행하여 as-if-jh-code-sync 브랜치에서 하위 파이프라인을 트리거하는 추가 단계가 있습니다. 이 작업은 JiHu 코드 동기화와 동일한 프로세스를 수행하여, 의존성 변경 사항이 검증 파이프라인을 실행하기 전에 as-if-jh 브랜치에 반영될 수 있도록 합니다.

의존성 변경이 없는 경우, 우리는 이 프로세스를 실행하지 않습니다.

as-if-JH 파이프라인을 트리거하고 실행하는 방법

as-if-jh/* 브랜치가 준비되고 선택적으로 동기화된 후, start-as-if-jh 작업이 검증 프로젝트에서 파이프라인을 트리거하여 크로스 프로젝트 하위 파이프라인을 실행합니다.

GitLab JH 미러 프로젝트 설정 방법

GitLab JH 미러 프로젝트는 비공개이며 CI가 비활성화되어 있습니다.

이 프로젝트는 GitLab JH에서 당겨오는 풀 미러로,

모든 브랜치를 미러링하며, 서로 다른 refs를 덮어쓰고,

미러가 업데이트될 때 파이프라인을 트리거하지 않습니다.

당겨오는 사용자는 @gitlab-jh-validation-bot로,

이 사용자는 프로젝트의 유지관리자입니다. 자격 증명은 1password

엔지니어링 금고에서 확인할 수 있습니다.

미러링에는 비밀번호가 사용되지 않습니다. GitLab JH는 공개 프로젝트입니다.

GitLab JH 검증 프로젝트 설정 방법

이 GitLab JH 검증 프로젝트는 공개이며 CI가 활성화되어 있으며,

임시 프로젝트 변수가 설정되어 있습니다.

이 프로젝트는 GitLab JH 미러에서 당겨오는 풀 미러로,

특정 브랜치들: (master|main-jh)를 미러링하며, 서로 다른 refs를 덮어쓰고,

미러가 업데이트될 때 파이프라인을 트리거하지 않습니다.

당겨오는 사용자는 @gitlab-jh-validation-bot로,

이 사용자는 프로젝트의 유지관리자이며,

GitLab JH 미러의 유지관리자이기도 합니다.

자격 증명은 1password 엔지니어링 금고에서 확인할 수 있습니다.

@gitlab-jh-validation-bot의 개인 접근 토큰에

write_repository 권한이 비밀번호로 사용되어 GitLab JH 미러에서 변경 사항을 당겨옵니다. 사용자 이름은 gitlab-jh-validation-bot으로 설정됩니다.

유지 관리 파이프라인을 실행하기 위한 파이프라인 일정이 있으며,

변수 SCHEDULE_TYPE이 maintenance로 설정되어 매일 실행되며 캐시를 업데이트합니다.

기본 CI/CD 구성 파일은 jh/.gitlab-ci.yml에 설정되어 있어

정확히 GitLab JH처럼 실행됩니다.

추가적으로, as-if-jh-code-sync라는 특별한 브랜치가 설정되어 보호되고 있습니다.

유지관리자는 이 브랜치에 푸시할 수 있으며, 개발자는 병합할 수 있습니다.

개발자가 이 브랜치에 대한 파이프라인을 트리거할 수 있도록 해야 하므로

이렇게 설정할 필요가 있습니다. 이는 보호된 브랜치에서 더 이상 파이프라인을 실행할 수 없는

Developer-level users no longer able to run pipelines on protected branches 문제를 해결하기 전의 타협입니다.

이는 병합 요청이 종속성을 변경했을 때 종속성을 동기화하기 위해 sync-as-if-jh-branch를 실행하는 데 사용됩니다.

어떻게 작동하는지 보려면 How we generate the as-if-JH branch를 참고하세요.

임시 GitLab JH 검증 프로젝트 변수

• BUNDLER_CHECKSUM_VERIFICATION_OPT_IN은 false로 설정됨
  • 이 변수는 JiHu가 jh/Gemfile.checksum를 커밋한 후 제거할 수 있습니다. 더 많은 맥락은 다음에서 확인할 수 있습니다: Setting it to false to skip it

우리는 왜 미러 프로젝트와 검증 프로젝트를 모두 가지고 있나요?

여러 가지 이유로 별도의 프로젝트를 두고 있습니다.

• 보안: 이전에는 미러 프로젝트만 있었습니다. 그러나 보안 문제를 완전히 완화하기 위해 미러 프로젝트를 비공개로 만들어야 했습니다.

• 격리: 우리는 JH 코드를 완전히 격리된 독립 프로젝트에서 실행하고 싶습니다. 미러 프로젝트가 있는 gitlab-org 그룹 아래에서 실행해서는 안 됩니다. 검증 프로젝트는 완전히 격리되어 있습니다.

• 비용: 우리는 각 병합 요청에서 JiHuLab.com에 연결하고 싶지 않습니다. JiHuLab.com에서 GitLab.com의 어딘가로 코드를 미러링하는 것이 더 비용 효율적이며, 우리의 병합 요청이 그곳에서 코드를 가져올 수 있습니다. 이는 검증 프로젝트가 JiHuLab.com이 아닌 미러에서 코드를 가져올 수 있게 한다는 것을 의미합니다. 미러 프로젝트는 주기적으로 JiHuLab.com에서 가져옵니다.

• 브랜치 분리/보안/효율성: 우리는 모든 브랜치를 미러링하고 싶습니다, 그래서 JiHuLab.com에서 해당 JH 브랜치를 가져올 수 있습니다. 그러나 검증 프로젝트의 as-if-jh-code-sync 브랜치를 덮어쓰고 싶지 않습니다, 왜냐하면 우리는 이를 검증 파이프라인을 제어하는 데 사용하며 AS_IF_JH_TOKEN에 접근할 수 있기 때문입니다. 그러나 우리는 특정 하나를 제외한 모든 브랜치를 미러링할 수 없습니다. 자세한 내용은 이 문제를 참조하세요.

  이 문제를 고려할 때, 검증 프로젝트는 master와 main-jh만 미러링하도록 설정되어 있습니다. 기술적으로 우리는 그 브랜치가 필요하지 않지만, 병합 요청에서 변경 사항을 푸시할 때 효율적으로 처리할 수 있도록 모든 기본 브랜치에 맞춰 레포지토리를 최신 상태로 유지하고 싶습니다.

• 관심사 분리:

  • 검증 프로젝트에는 다음 브랜치만 있습니다:
    • 변경 사항을 최신 상태로 유지하기 위한 master와 main-jh.
    • 의존성 동기화를 위한 as-if-jh-code-sync. 우리는 이것을 절대 미러링해서는 안 됩니다.
    • 병합 요청에서 오는 as-if-jh/* 브랜치. 우리는 이것들을 절대 미러링해서는 안 됩니다.
  • 미러 프로젝트의 모든 브랜치는 JiHuLab.com에서 오는 것입니다. 우리는 미러 프로젝트에 아무것도 푸시하지 않으며, 파이프라인을 실행하지도 않습니다. CI/CD는 미러 프로젝트에서 비활성화되어 있습니다.

설정을 단순화하기 위해 두 프로젝트를 병합하는 것을 고려할 수 있지만, 이러한 모든 이유가 더 이상 문제가 되지 않도록 해야 합니다.

rspec:undercoverage 작업

rspec:undercoverage 작업은 undercover를 실행하여, 병합 요청에 도입된 변경 사항 중 커버리지가 0인 경우를 감지하고 실패합니다.

rspec:undercoverage 작업은 rspec:coverage 작업에서 커버리지 데이터를 가져옵니다.

rspec:undercoverage 작업이 CE 메서드가 EE에서 재정의로 인해 커버리지가 부족하다고 감지하면, 병합 요청에 pipeline:run-as-if-foss 라벨을 추가하고 새 파이프라인을 시작하세요.

비상 사태나 이 작업에서 잘못된 긍정이 발생한 경우, 병합 요청에 pipeline:skip-undercoverage 라벨을 추가하여 이 작업이 실패하도록 허용하세요.

rspec:undercoverage 실패 문제 해결

rspec:undercoverage 작업에는 알려진 버그가 있어 가짜 양성 실패를 유발할 수 있습니다. 이러한 가짜 양성 실패는 너무 오래된 데이터베이스 마이그레이션을 업데이트하는 경우에도 발생할 수 있습니다.

로컬에서 커버리지를 테스트하여 pipeline:skip-undercoverage를 적용해도 안전한지 확인할 수 있습니다. 예를 들어, 실패를 유발하는 테스트의 이름으로 <spec>을 사용하는 경우:

1. RUN_ALL_MIGRATION_TESTS=1 SIMPLECOV=1 bundle exec rspec <spec>을 실행합니다.
2. scripts/undercoverage를 실행합니다.

이 명령어가 undercover: ✅ No coverage is missing in latest changes를 반환하면 파이프라인 실패를 우회하기 위해 pipeline:skip-undercoverage를 적용할 수 있습니다.

pajamas_adoption 작업

• GitLab 16.8에서 도입됨.

pajamas_adoption 작업은 병합 요청에서 Pajamas Adoption Scanner를 실행하여 Pajamas Design System의 채택 과정에서 회귀를 방지합니다.

스캐너가 병합 요청으로 인해 발생한 회귀를 감지하면 작업이 실패합니다. 회귀를 병합 요청에서 수정할 수 없는 경우, 병합 요청에 pipeline:skip-pajamas-adoption 레이블을 추가한 다음 작업을 다시 시도합니다.

테스트 스위트 병렬화

현재 RSpec 테스트 병렬화 설정은 다음과 같습니다:

1. prepare 단계의 retrieve-tests-metadata 작업은 knapsack/report-master.json 파일이 있는지 확인합니다:
   • knapsack/report-master.json 파일은 update-tests-metadata를 실행하는 최신 main 파이프라인에서 가져옵니다 (현재는 2시간마다 실행되는 maintenance 예정 마스터 파이프라인입니다). 여기에 없으면 파일을 {}로 초기화합니다.
2. 각 [rspec|rspec-ee] [migration|unit|integration|system|geo] n m 작업은 knapsack rspec으로 실행되며 테스트의 고른 분배를 가져야 합니다:
   • 이전 단계의 모든 아티팩트는 기본적으로 전달되기 때문에 작업이 knapsack/report-master.json에 접근할 수 있습니다.
   • 작업은 자신의 보고서 경로를 "knapsack/${TEST_TOOL}_${TEST_LEVEL}_${DATABASE}_${CI_NODE_INDEX}_${CI_NODE_TOTAL}_report.json"으로 설정합니다.
   • knapsack이 제대로 작동하면 실행된 테스트 파일은 Report specs 아래에 나열되어야 하며, Leftover specs 아래에는 나열되어서는 안 됩니다.
3. update-tests-metadata 작업(이는 정규 프로젝트의 예정된 파이프라인에서만 실행되며 knapsack/report-master.json을 두 가지 방식으로 업데이트합니다):
   1. 기본적으로 모든 knapsack/rspec*.json 파일을 가져와서 하나의 knapsack/report-master.json 파일로 병합하여 아티팩트로 저장합니다.
   2. (실험적) AVERAGE_KNAPSACK_REPORT 환경 변수가 true로 설정되면, 보고서를 병합하는 대신, 작업은 knapsack/report-master.json과 knapsack/rspec*.json 간의 테스트 지속 시간 평균을 계산하여 스펙 순서, 러너 하드웨어의 차이, 불안정한 테스트 등과 같은 잠재적으로 무작위적인 요인에서 성능 영향을 줄입니다. 이 실험적 접근법은 병렬 작업 간의 부하를 더 고르게 분배하고, 작업이 비슷한 시간에 완료될 수 있도록 각 스펙 파일의 지속 시간을 더 잘 예측하는 것을 목표로 합니다.

그 후, 다음 파이프라인은 최신 knapsack/report-master.json 파일을 사용합니다.

흔들리는 테스트

흔들리는 테스트의 자동 스킵

우리는 흔들리는 것으로 알려진 테스트를 건너뛰곤 했지만, 이는 실제로 master가 깨질 수 있는 원인이 될 수 있기 때문에 이제 그만두었습니다.

대신 우리는 #master-broken 사건에서 보고된 모든 흔들리는 테스트를 능동적으로 격리하기 위해 빠른 격리 프로세스를 도입했습니다.

이 빠른 격리 프로세스는 $FAST_QUARANTINE 변수를 false로 설정하면 비활성화할 수 있습니다.

별도의 프로세스에서 실패한 테스트의 자동 재시도

$RETRY_FAILED_TESTS_IN_NEW_PROCESS 변수가 false로 설정되지 않는 한 (기본값은 true), 실패한 RSpec 테스트는 별도의 RSpec 프로세스에서 자동으로 한 번 재시도됩니다. 목표는 후속 테스트 실패를 초래할 수 있는 이전 테스트의 대부분의 부작용을 없애는 것입니다.

우리는 $RETRIED_TESTS_REPORT_FILE 파일에 재시도된 테스트를 기록하며, 이 파일은 rspec:flaky-tests-report 작업에 의해 아티팩트로 저장됩니다.

실험 문제를 참조하세요.

호환성 테스트

기본적으로 우리는 GitLab.com에서 실행되는 버전으로 모든 테스트를 실행합니다.

다른 버전 (일반적으로 하나의 이전 버전과 하나의 다음 호환 버전)은 야간 예약 파이프라인에서 실행되어야 합니다.

이 일반 가이드라인에 대한 예외는 동기가 부여되고 문서화되어야 합니다.

루비 버전 테스트

우리는 GitLab.com 및 기본 브랜치에서 Ruby 3.1을 실행하고 있습니다.

다음 Ruby 버전을 준비하기 위해, 우리는 Ruby 3.2에서 병합 요청을 실행합니다.

자세한 내용은 Ruby 3.2 에픽에서 확인하세요.

모든 지원되는 Ruby 버전이 작동하는지 확인하기 위해, 우리는 각 지원 버전마다 전용 2시간 간격의 예약 파이프라인에서 테스트 스위트를 실행합니다.

병합 요청의 경우, 다음 레이블을 추가하여 해당 Ruby 버전만 실행할 수 있습니다:

• pipeline:run-in-ruby3_1

PostgreSQL 버전 테스트

우리의 테스트 스위트는 PostgreSQL 14에서 실행되며, 이는 GitLab.com이 PostgreSQL 14에서 실행되고 있고 Omnibus는 새 설치 및 업그레이드를 위해 PG14를 기본값으로 사용합니다.

우리는 야간 예약 파이프라인에서 PostgreSQL 14, 15 및 16에 대해 테스트 스위트를 실행합니다.

현재 버전 테스트

각 현재 Ruby 버전 별로, 우리는 해당 ruby\d_\d 브랜치에서 매 2시간마다 유지보수 예약 파이프라인을 실행합니다. 이러한 브랜치는 변경 사항이 없어야 합니다. 이러한 브랜치는 예약된 유지보수 파이프라인에서 해당 Ruby 버전으로 파이프라인을 실행하기 위해 존재합니다.

또한, 우리는 ruby-sync 브랜치에서 매 2시간마다 예약 파이프라인을 실행하여 모든 ruby\d_\d 브랜치를 기본 브랜치 master로 업데이트합니다. 이 푸시를 통해 파이프라인이 트리거되지 않습니다.

ruby-sync 브랜치의 gitlab 작업은 RUBY_SYNC라는 프로젝트 토큰을 사용하며, 이 토큰은 write_repository 권한과 Maintainer 역할을 가지고 있습니다. 만료일은 2024-12-01입니다. 이 토큰은 ruby-sync 브랜치의 파이프라인 예약에서 RUBY_SYNC_TOKEN 변수에 저장됩니다.

Redis 버전 테스트

우리 테스트 스위트는 GitLab.com이 Redis 6에서 실행되기 때문에 Redis 6에서 실행됩니다.

Omnibus는 새 설치 및 업그레이드에 대해 Redis 6를 기본값으로 설정합니다.

우리는 또한 ‘nightly’ 예약된 파이프라인에서 Redis 7에 대해 테스트 스위트를 실행하며, 특히 PostgreSQL 15 작업을 실행할 때 호환 가능합니다.

현재 버전 테스트

단일 데이터베이스 테스트

기본적으로 모든 테스트는 다중 데이터베이스로 실행됩니다.

우리는 또한 단일 데이터베이스로 테스트를 실행하는데, 이는 nightly 예약된 파이프라인과 데이터베이스 관련 파일을 수정하는 병합 요청에서 실행됩니다.

단일 데이터베이스 테스트는 두 가지 모드로 진행됩니다:

1. 단일 연결로 단일 데이터베이스. GitLab이 하나의 연결 풀을 사용하여 모든 테이블에 연결합니다. 이는 -single-db로 끝나는 모든 작업을 통과합니다.

2. 두 개의 연결로 단일 데이터베이스. GitLab이 서로 다른 데이터베이스 연결을 사용하여 gitlab_main, gitlab_ci 데이터베이스 테이블에 연결합니다. 이는 -single-db-ci-connection로 끝나는 모든 작업을 통과합니다.

단일 데이터베이스로 실행하도록 테스트를 강제하려면 병합 요청에 pipeline:run-single-db 레이블을 추가하면 됩니다.

모니터링

GitLab 테스트 스위트는 모니터링됩니다 main 브랜치와 이름에 rspec-profile이 포함된 모든 브랜치에 대해.

로깅

• Rails 로깅은 기본적으로 CI에서 log/test.log에 대해 비활성화되어 있습니다. 성능상의 이유로. 이 설정을 재정의하려면 RAILS_ENABLE_TEST_LOG 환경 변수를 제공하세요.

병합 요청을 위한 파이프라인 유형

일반적으로 MR을 위한 파이프라인은 MR에 적용된 변경 사항에 따라 다음 유형 중 하나로 분류됩니다(짧은 것에서 긴 것까지):

• 문서 파이프라인: 문서를 수정하는 MRs를 위한 것입니다.
• 백엔드 파이프라인: 백엔드 코드를 수정하는 MRs를 위한 것입니다.
• 리뷰 앱 파이프라인: 프런트엔드 코드를 수정하는 MRs를 위한 것입니다.
• 종단 간 파이프라인: qa/ 폴더의 코드를 수정하는 MRs를 위한 것입니다.

“파이프라인 유형”은 주로 “중요 경로”를 설명하는 추상적인 용어입니다(예: 개별 지속 시간의 합이 파이프라인의 지속 시간과 같은 작업 체인).

우리는 이러한 “파이프라인 유형”을 메트릭 대시보드에서 사용하여 어떤 유형과 작업을 먼저 최적화해야 하는지 감지합니다.

다수의 영역을 수정하는 MR은 적용 가능한 가장 긴 유형과 연결됩니다. 예를 들어, 백엔드와 프런트엔드를 수정하는 MR은 “프런트엔드” 파이프라인 유형에 포함되며, 이 유형은 “백엔드” 파이프라인 유형보다 완료하는 데 더 오랜 시간이 걸립니다.

우리는 rules: 및 needs: 키워드를 광범위하게 사용하여 파이프라인에서 실행해야 하는 작업을 결정합니다. 여러 유형의 변경 사항이 포함된 MR은 여러 유형의 작업을 포함하는 파이프라인을 가질 수 있습니다(예: 독립 문서와 코드 전용 파이프라인의 조합).

다음은 각 파이프라인 유형에 대한 중요한 경로의 그래프입니다. 중요한 경로의 일부가 아닌 작업은 생략됩니다.

문서 파이프라인

참조 파이프라인.

백엔드 파이프라인

참조 파이프라인.

리뷰 앱 파이프라인

참조 파이프라인.

엔드 투 엔드 파이프라인

참조 파이프라인.

CI 구성 내부

전문 CI 구성 내부 페이지를 참조하세요.

성능

전문 CI 구성 성능 페이지를 참조하세요.

개발 문서로 돌아가기