gitlab-org/gitlab(dev 인스턴스 포함)의 파이프라인은 일반적인 .gitlab-ci.yml에 구성되어 있으며, 유지 관리를 편리하게 하기 위해 .gitlab/ci/ 하위 파일들을 포함합니다.

우리는 가능한 한 GitLab CI/CD 기능과 모범 사례를 dogfood하기 위해 노력합니다.

dev.gitlab.com 인스턴스에 미러링되지 않은 CI/CD 컴포넌트는 gitlab-org/gitlab 파이프라인에서 사용하지 마세요. CI/CD 컴포넌트는 서로 다른 인스턴스 간에 작동하지 않으며, 해당 인스턴스에 존재하지 않으면 dev.gitlab.com 미러에서 파이프라인 실패를 유발합니다.

파이프라인 티어#

머지 리퀘스트는 일반적으로 여러 CI/CD 파이프라인을 실행합니다. 머지 리퀘스트가 승인 프로세스에서 어느 단계에 있는지에 따라 다른 종류의 파이프라인이 트리거됩니다. 이러한 파이프라인 종류를 파이프라인 티어라고 합니다.

현재 세 가지 티어가 있습니다:

• pipeline::tier-1: 머지 리퀘스트에 승인이 없는 경우

• pipeline::tier-2: 머지 리퀘스트에 하나 이상의 승인이 있지만 아직 더 많은 승인이 필요한 경우

• pipeline::tier-3: 머지 리퀘스트에 필요한 모든 승인이 완료된 경우

일반적으로 파이프라인 티어가 낮을수록 파이프라인 속도가 빨라야 합니다. 파이프라인 티어가 높을수록 더 많은 테스트를 실행하여 더 높은 신뢰도를 제공해야 합니다.

구현에 대한 자세한 내용은 MR 파이프라인에서 "티어" 도입 에픽을 참조하세요.

머지 리퀘스트 승인 전 예측 테스트 job#

파이프라인 비용을 줄이고 job 실행 시간을 단축하기 위해, 머지 리퀘스트가 승인되기 전에 파이프라인은 해당 머지 리퀘스트 변경 사항에서 실패할 가능성이 높은 RSpec 및 Jest 테스트의 예측 집합을 실행합니다.

머지 리퀘스트가 승인된 후에는 파이프라인에 전체 RSpec 및 Jest 테스트가 포함됩니다. 이를 통해 머지 리퀘스트가 병합되기 전에 모든 테스트가 실행되었는지 확인합니다.

GitLab 프로젝트 테스트 의존성 개요#

예측 테스트 job이 어떻게 실행되는지 이해하려면 GitLab 코드(프론트엔드 및 백엔드)와 각 테스트(Jest 및 RSpec) 간의 의존성을 이해해야 합니다. 이 의존성은 다음 다이어그램으로 시각화할 수 있습니다:

flowchart LR subgraph frontend fe["Frontend code"]--tested with-->jest end subgraph backend be["Backend code"]--tested with-->rspec end

be--generates-->fixtures["frontend fixtures"]
fixtures--used in-->jest

요약하면:

• RSpec 테스트는 백엔드 코드에 의존합니다.

• Jest 테스트는 프론트엔드 및 백엔드 코드 모두에 의존하며, 후자는 프론트엔드 픽스처를 통해 의존합니다.

detect-tests CI job#

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

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

RSpec 예측 job#

머지 리퀘스트에서 예측 RSpec 테스트 파일 결정#

머지 리퀘스트에서 실패할 가능성이 높은 RSpec 테스트를 식별하기 위해 동적 매핑과 정적 매핑을 사용합니다.

동적 매핑#

먼저 test_file_finder gem을 사용하며, Crystalball gem)에서 제공하는 동적 매핑 전략을 활용합니다 (사용 위치 보기 및 Crystalball에서 사용하는 매핑 전략).

test_file_finder 외에도 더 많은 테스트를 감지하기 위한 여러 고급 매핑을 추가했습니다:

• FindChanges (!74003)

백엔드 변경 사항에 대해 실행할 Jest 테스트를 자동으로 감지합니다(프론트엔드 픽스처를 통해).

• PartialToViewsMappings (#395016)

MR에서 해당 뷰에 포함된 Rails 파셜이 변경될 때 뷰 스펙을 실행합니다.

• JsToSystemSpecsMappings (#386754)

MR에서 JavaScript 파일이 변경된 경우 특정 시스템 스펙을 실행합니다.

• GraphqlBaseTypeMappings (#386756)

GraphQL 타입 클래스가 변경된 경우, 해당 타입을 포함하는 다른 GraphQL 타입을 식별하고 해당 스펙을 실행합니다.

• ViewToSystemSpecsMappings (#395017)

뷰가 변경되면 해당 코드 영역을 테스트하는 기능 스펙을 찾으려 합니다.

• ViewToJsMappings (#386719)

JS 파일이 변경되면 해당 JS 컴포넌트를 다루는 시스템 스펙을 식별하려 합니다.

• FindFilesUsingFeatureFlags (#407366)

피처 플래그가 변경된 경우, 해당 피처 플래그를 포함하는 Ruby 파일을 확인하여 detect-tests CI job의 변경된 파일 목록에 추가합니다. 그러면 job의 나머지 부분이 변경된 파일을 기반으로 실행할 프론트엔드/백엔드 테스트를 감지합니다.

정적 매핑#

동적 매핑으로 매핑할 수 없는 특수한 경우를 위해 tests.yml 파일에 유지되는 정적 매핑을 사용하여 test_file_finder gem을 활용합니다 (사용 위치 보기).

테스트 매핑에는 각 소스 파일을 해당 소스 파일에 의존하는 테스트 파일 목록으로 매핑한 내용이 포함되어 있습니다.

예외 사례#

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

• 머지 리퀘스트에 pipeline:run-all-rspec 라벨이 설정된 경우. 이 라벨은 as-if-foss job에서 실행되는 테스트를 포함한 모든 RSpec 테스트를 트리거합니다.

• 머지 리퀘스트에 pipeline:mr-approved 라벨이 설정되어 있고, 코드 변경 사항이 backend-patterns 규칙을 충족하는 경우. 이 라벨은 머지 리퀘스트가 검토자에게 승인되면 트리아지 자동화에 의해 할당됩니다. 이 라벨을 수동으로 적용하는 것은 권장하지 않습니다.

• 머지 리퀘스트가 자동화에 의해 생성된 경우(예: Gitaly 업데이트 또는 안정 브랜치를 타깃으로 하는 MR)

• 머지 리퀘스트가 보안 미러에서 생성된 경우

• CI 구성 파일이 변경된 경우(예: .gitlab-ci.yml 또는 .gitlab/ci/**/*)

백엔드 예측 테스트 문제가 발생했나요?#

그렇다면 예측 테스트 문제에 대응하는 방법에 대한 지침은 예측 테스트에 대한 Development Analytics RUNBOOK을 참조하세요. 또한 테스트 선택 누락을 발견한 경우, 필요한 조치를 취할 수 있도록 @gl-dx/development-analytics에 알려주세요.

GitLab Duo 시스템 테스트 선택#

tier-2 파이프라인에서 GitLab Duo는 MR 변경 사항과 관련된 시스템 스펙을 예측합니다. 이는 detect-tests job에 추가로 실행되며 시스템 스펙 (spec/features/ 및 ee/spec/features/)에 한정됩니다.

작동 방식#

detect-system-tests-duo job은 MR diff에 대해 GitLab Duo CLI를 호출합니다. 그런 다음 PreparePredictiveSystemPipeline 스크립트가 출력을 처리하고 파이프라인 입력을 준비합니다:

• GitLab Duo가 확신하는 경우: GitLab Duo 예측은 detect-tests가 선택한 시스템 테스트와 병합됩니다(합집합). 예측 파이프라인은 결합된 집합을 실행합니다. GitLab Duo가 시스템 테스트가 필요 없다고 예측하면 detect-tests가 선택한 테스트만 실행됩니다.

• GitLab Duo가 확신하지 못하거나 실패하는 경우: 시스템 테스트는 예측 파이프라인에서 제거됩니다. 전체 시스템 테스트 스위트는 전용 하위 파이프라인(rspec-predictive-system-full)에서 실행됩니다.

범위#

GitLab Duo 시스템 테스트 선택은 gitlab-org/gitlab tier-2 파이프라인에서만 실행됩니다. 다음의 경우 건너뜁니다:

• pipeline:run-all-rspec 라벨이 설정된 경우(전체 스위트가 이미 실행됨).

• pipeline:spec-only 라벨이 설정된 경우(detect-tests가 이미 스펙 파일을 직접 식별함).

• 변경 사항이 코어 백엔드 또는 workhorse 패턴과 일치하는 경우(이러한 변경 사항에 대해 메인 파이프라인에서 이미 모든 시스템 테스트가 실행됨).

tier-3 파이프라인에서는 job이 메트릭 수집을 위해 실행되지만 출력이 테스트 선택에 영향을 미치지 않습니다.

코드 변경 없이 GitLab Duo 시스템 테스트 선택을 비활성화하려면 GLCI_DUO_SYSTEM_TESTS_DISABLED CI/CD 프로젝트 변수를 "true"로 설정하세요. 비활성화되면 detect-system-tests-duo job을 건너뛰고 tier-2에서 전체 시스템 테스트 스위트가 폴백으로 실행됩니다.

Jest 예측 job#

머지 리퀘스트에서 예측 Jest 테스트 파일 결정#

머지 리퀘스트에서 실패할 가능성이 높은 Jest 테스트를 식별하기 위해 --findRelatedTests 옵션을 사용하여 변경된 모든 파일 목록을 jest에 전달합니다. 이 모드에서 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에 정의되어 있습니다.

프론트엔드 예측 테스트 문제가 발생했나요?#

그렇다면 예측 테스트 문제에 대응하는 방법에 대한 지침은 예측 테스트에 대한 Development Analytics RUNBOOK을 참조하세요.

포크 파이프라인#

포크 파이프라인의 경우 MR에 pipeline:run-all-rspec 라벨이 설정되어 있지 않는 한 예측 RSpec 및 Jest job만 실행합니다. 목표는 포크 파이프라인이 소비하는 컴퓨팅 할당량을 줄이는 것입니다.

실험 이슈를 참조하세요.

머지 리퀘스트 파이프라인의 빠른 실패 job#

머지 리퀘스트가 기존 테스트를 중단시켰을 때 더 빠른 피드백을 제공하기 위해 빠른 실패 메커니즘을 구현했습니다.

rspec fail-fast job은 머지 리퀘스트 파이프라인의 다른 모든 rspec job과 병렬로 추가됩니다. 이 job은 머지 리퀘스트의 변경 사항과 직접 관련된 테스트를 실행합니다.

이 테스트 중 하나라도 실패하면 rspec fail-fast job이 실패하고 fail-pipeline-early job이 실행됩니다. fail-pipeline-early job은:

• 현재 실행 중인 파이프라인과 진행 중인 모든 job을 취소합니다.

• 파이프라인 상태를 failed로 설정합니다.

예시:

graph LR subgraph "prepare stage"; A["detect-tests"] end

subgraph "test stage";
    B["jest"];
    C["rspec migration"];
    D["rspec unit"];
    E["rspec integration"];
    F["rspec system"];
    G["rspec fail-fast"];
end

subgraph "post-test stage";
    Z["fail-pipeline-early"];
end

A --"artifact: list of test files"--> G
G --"on failure"--> Z

rspec fail-fast는 머지 리퀘스트와 관련된 테스트 파일이 10개를 초과하면 아무 작업도 하지 않습니다(no-op). 이는 rspec fail-fast 실행 시간이 평균 rspec job 실행 시간을 초과하여 목적을 상실하는 것을 방지합니다.

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

머지 리퀘스트 파이프라인에서 이전에 실패한 테스트 재실행#

머지 리퀘스트에서 실패한 테스트를 해결한 후 피드백 시간을 줄이기 위해 rspec rspec-pg17-rerun-previous-failed-tests 및 rspec rspec-ee-pg17-rerun-previous-failed-tests job이 이전 MR 파이프라인에서 실패한 테스트를 실행합니다.

이는 2021년 8월 25일 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69053으로 도입되었습니다.

실패한 테스트 재실행 방법#

• detect-previous-failed-tests job(prepare Stage)이 이전 MR 파이프라인에서 실패한 RSpec job과 연관된 테스트 파일을 감지합니다.

• rspec rspec-pg17-rerun-previous-failed-tests 및 rspec rspec-ee-pg17-rerun-previous-failed-tests job이 detect-previous-failed-tests job에 의해 수집된 테스트 파일을 실행합니다.

graph LR subgraph "prepare stage"; A["detect-previous-failed-tests"] end

subgraph "test stage";
    B["rspec rspec-pg17-rerun-previous-failed-tests"];
    C["rspec rspec-ee-pg17-rerun-previous-failed-tests"];
end

A --"artifact: list of test files"--> B & C

머지 트레인#

현재 사용#

2024년 6월에 머지 트레인 사용을 시작했습니다.

현재 머지 트레인 파이프라인은 테스트를 실행하지 않습니다: 머지 트레인 활성화 전에 이미 존재했지만 쉽게 강제할 수 없었던 머지 리퀘스트 병합 가이드라인만 강제합니다.

머지 트레인 파이프라인은 병합 전 최신 파이프라인이 다음 조건을 충족하는지 확인하는 단일 pre-merge-checks job을 실행합니다:

• 병합된 결과 파이프라인일 것

• tier-3 파이프라인일 것(예측 파이프라인이 아닌 전체 파이프라인)

• 최대 16시간 전에 생성되었을 것(안정 브랜치의 경우 72시간)

이 솔루션을 개선하기 위해 피드백 이슈를 열었습니다.

다음 반복#

실제로 머지 트레인 파이프라인에서 테스트를 실행하기 위한 머지 트레인 다음 반복을 논의하는 전용 이슈를 열었습니다.

"전체" 테스트 파이프라인을 실행하는 머지 트레인 활성화 과제#

왜 "안정적인" 기본 브랜치가 필요한가요?#

기본 브랜치가 불안정한 경우(예: 기본 브랜치에 대한 CI/CD 파이프라인이 자주 실패하는 경우), 결함이 있는 머지 리퀘스트 파이프라인 이후에 추가된 모든 머지 리퀘스트 파이프라인은 취소되고 트레인에 다시 추가되어야 하며, 머지 트레인이 길 경우 많은 지연이 발생합니다.

기본 브랜치는 얼마나 안정적이어야 하나요?#

구체적인 숫자는 없지만, 플레이키 테스트 실패 및 인프라 실패에 대한 수치를 개선해야 합니다(Master Broken Incidents RCA Dashboard 참조).

일부 머지 리퀘스트에 대한 빠른 피드백#

브레이크된 master 수정#

브레이크된 master를 수정해야 할 경우, 머지 리퀘스트에서 실행되는 파이프라인을 신속히 처리하기 위해 pipeline::expedited 라벨을 추가할 수 있습니다.

머지 리퀘스트에 master:broken 또는 master:foss-broken 라벨도 설정되어 있어야 합니다.

리버트 MR#

리버트 MR을 빠르게 처리하려면 머지 리퀘스트를 생성하기 전에 revert MR 템플릿을 사용하세요. 이렇게 하면 pipeline::expedited 라벨 및 기타 라벨이 적용되어 머지 리퀘스트에서 실행되는 파이프라인이 신속히 처리됩니다.

pipeline::expedited 라벨#

이 라벨이 할당되면 CI/CD 파이프라인의 다음 단계가 건너뜁니다:

• e2e:test-on-omnibus-ee job.

• rspec:undercoverage job.

머지 리퀘스트에 라벨을 적용하고 MR에 대한 새 파이프라인을 실행하세요.

테스트 job#

각 테스팅 레벨에 전용 job이 있으며, 각 job은 머지 리퀘스트에서 수행한 변경 사항에 따라 실행됩니다. 변경 사항에 관계없이 모든 RSpec job을 강제로 실행하려면 머지 리퀘스트에 pipeline:run-all-rspec 라벨을 추가할 수 있습니다.

문서 전용 관련 MR에서 모든 job을 강제로 실행하면 전제 조건 job이 없어 오류가 발생합니다.

End-to-end job#

자세한 내용은 End-to-end 테스트 파이프라인을 참조하세요.

Observability end-to-end job#

GitLab Observability Backend에는 GitLab 인스턴스에 대해 실행되는 전용 end-to-end 테스트가 있습니다. 이 테스트는 GitLab과 Observability Backend 간의 통합이 올바르게 작동하는지 확인하기 위해 설계되었습니다.

GitLab 파이프라인에는 GitLab MR에서 실행할 수 있는 전용 job이 있습니다(observability-backend.gitlab-ci.yml 참조). 이 job들은 GitLab MR 브랜치에서 빌드된 GitLab 인스턴스에 대해 GitLab Observability Backend 파이프라인에서 E2E 테스트를 트리거합니다. 이 job들은 검토 중인 GitLab 변경 사항이 GitLab Observability Backend 파이프라인의 E2E 테스트를 중단시키지 않는지 확인하는 데 유용합니다.

Observability end-to-end job은 두 가지가 있습니다:

• e2e:observability-backend-main-branch: GitLab Observability Backend의 main 브랜치에 대해 테스트를 실행합니다.

• e2e:observability-backend: MR 브랜치와 동일한 이름을 가진 GitLab Observability Backend의 브랜치에 대해 테스트를 실행합니다.

Observability E2E job은 lib/gitlab/observability/ 디렉터리에 있는 파일이나 Observability 기능과 관련된 특정 구성 파일 등 관련 파일을 다루는 머지 리퀘스트에 대해서만 자동으로 트리거됩니다.

이 job들을 수동으로 실행하려면 머지 리퀘스트에 pipeline:run-observability-e2e-tests-main-branch 또는 pipeline:run-observability-e2e-tests-current-branch 라벨을 추가할 수 있습니다.

다음 예시 워크플로에서 개발자는 Observability 코드를 수정하는 MR을 생성하고 Observability end-to-end job을 사용합니다:

• 개발자가 Observability 코드를 수정하는 GitLab MR을 생성합니다. MR이 자동으로 e2e:observability-backend-main-branch job을 실행합니다.

• e2e:observability-backend-main-branch가 실패하면 MR이 무언가를 중단시켰거나(수정 필요) MR의 변경 사항으로 인해 e2e 테스트를 업데이트해야 함을 의미합니다.

• e2e 테스트를 업데이트하기 위해 개발자는:

중단하는 변경 사항이 있는 GitLab 브랜치와 동일한 이름으로 GitLab Observability Backend 리포지터리에 브랜치를 생성합니다.

• e2e 테스트를 수정합니다.

• 변경 사항으로 머지 리퀘스트를 생성합니다.

• 개발자는 GitLab MR에 pipeline:run-observability-e2e-tests-current-branch 라벨을 추가하고 e2e:observability-backend job이 성공할 때까지 기다립니다.

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

또한 개발자는 수동으로 pipeline:run-observability-e2e-tests-main-branch를 추가하여 MR이 e2e:observability-backend-main-branch job을 강제로 실행하도록 할 수 있습니다. 이는 Observability와 관련된 것으로 추적되지 않는 파일에 변경 사항이 있는 경우 유용할 수 있습니다.

테스트를 건너뛰어야 하는 상황이 있을 수 있습니다. 테스트를 건너뛰려면:

• MR의 경우 pipeline:skip-observability-e2e-tests label 라벨을 적용합니다.

• 전체 프로젝트의 경우 CI 변수 SKIP_GITLAB_OBSERVABILITY_BACKEND_TRIGGER를 설정합니다.

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

FOSS 프로젝트에서 관련 변경 사항이 올바르게 작동하는지 확인하기 위해 일부 조건에서 다음도 실행합니다:

• 동일한 파이프라인에서 * as-if-foss job

• 크로스 프로젝트 다운스트림 FOSS 파이프라인

* as-if-foss job은 GitLab 테스트 스위트를 "FOSS인 것처럼", 즉 job이 gitlab-org/gitlab-foss 컨텍스트에서 실행되는 것처럼 실행합니다. 반면, 크로스 프로젝트 다운스트림 FOSS 파이프라인은 실제로 FOSS 프로젝트 내에서 실행되어 실제 FOSS 환경에 훨씬 더 가깝습니다.

다음과 같은 경우에 실행됩니다:

• 머지 리퀘스트에 pipeline:run-as-if-foss 라벨이 설정된 경우

• 머지 리퀘스트에 pipeline:as-if-foss-run-predictive 라벨이 설정된 경우 (FOSS 파이프라인에서 예측 테스트, RuboCop, eslint, 정적 분석만 실행)

• 머지 리퀘스트가 gitlab-org/security/gitlab 프로젝트에서 생성된 경우

• CI 구성 파일이 변경된 경우(예: .gitlab-ci.yml 또는 .gitlab/ci/**/*)

* as-if-foss job은 일반 EE 컨텍스트 job에 추가하여 실행됩니다. 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: developer 권한과 write_repository 권한을 가진 GitLab FOSS 프로젝트 토큰으로, 생성된 as-if-foss/* 브랜치를 푸시하기 위해 사용됩니다.

보안 프로젝트의 동일 이름은 보안 변경 사항을 공개 프로젝트에 절대 푸시하지 않도록 보안 FOSS 프로젝트의 다른 토큰을 사용해야 합니다.

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

무엇인가요?#

이 파이프라인은 JiHu 검증 파이프라인이라고도 하며, 현재 실패가 허용됩니다. 그런 경우 검증 파이프라인이 실패했을 때 해야 할 일을 따르세요.

실행 방법#

start-as-if-jh job은 GitLab 테스트 스위트를 "JiHu인 것처럼", 즉 파이프라인이 GitLab JH 컨텍스트에서 실행되는 것처럼 실행하는 크로스 프로젝트 다운스트림 파이프라인을 트리거합니다. 이 job들은 다음의 경우에만 생성됩니다:

• 피처 플래그에 변경이 있는 경우

• 머지 리퀘스트에 pipeline:run-as-if-jh 라벨이 설정된 경우

이 파이프라인은 GitLab JH mirror의 미러인 GitLab JH validation 프로젝트에서 생성된 브랜치의 컨텍스트에서 실행됩니다.

생성된 브랜치 이름에는 머지 리퀘스트의 브랜치 이름과 함께 as-if-jh/ 접두사가 붙습니다. 이 생성된 브랜치는 머지 리퀘스트 브랜치를 기반으로 하며, 파이프라인 전체를 JiHu인 것처럼 만들기 위해 해당 JH 브랜치에서 다운로드된 변경 사항을 추가합니다.

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

pipeline:run-as-if-jh 라벨 적용을 고려할 시기#

Ruby 파일의 이름이 변경되고 해당 prepend_mod 라인이 있는 경우, GitLab JH가 이에 의존하고 있을 가능성이 높으므로 프리펜드하는 모듈이나 클래스의 이름을 바꾸는 해당 변경이 필요합니다.

해당 JH 브랜치#

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

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

GitLab JH validation은 GitLab JH mirror의 미러이지만, 기본 main-jh 외에는 해당 JH 브랜치를 포함하지 않습니다. 이것이 해당 JH 브랜치를 가져오려 할 때 검증 프로젝트가 아닌 메인 미러에서 가져와야 하는 이유입니다.

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

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

의존성 변경이 있는 경우에만 sync-as-if-jh-branch를 실행합니다.

flowchart TD subgraph "JiHuLab.com" JH["gitlab-cn/gitlab"] end

subgraph "GitLab.com" Mirror["gitlab-org/gitlab-jh-mirrors/gitlab"]

subgraph MR["gitlab-org/gitlab merge request"]
  Add["add-jh-files job"]
  Prepare["prepare-as-if-jh-branch job"]
  Add --"download artifacts"--> Prepare
end

subgraph "gitlab-org-sandbox/gitlab-jh-validation"
  Sync["(*optional) sync-as-if-jh-branch job on branch as-if-jh-code-sync"]
  Start["start-as-if-jh job on as-if-jh/* branch"]
  AsIfJH["as-if-jh pipeline"]
end

Mirror --"pull mirror with master and main-jh"--> gitlab-org-sandbox/gitlab-jh-validation
Mirror --"download JiHu files with ADD_JH_FILES_TOKEN"--> Add
Prepare --"push as-if-jh branches with AS_IF_JH_TOKEN"--> Sync
Sync --"push as-if-jh branches with AS_IF_JH_TOKEN"--> Start
Start --> AsIfJH

end

JH --"pull mirror with corresponding JH branches"--> Mirror

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

• ADD_JH_FILES_TOKEN: JiHu 파일을 다운로드할 수 있도록 read_api 권한을 가진 GitLab JH mirror 프로젝트 토큰입니다.

• AS_IF_JH_TOKEN: 생성된 as-if-jh/* 브랜치를 푸시하기 위해 developer 권한과 write_repository 권한을 가진 GitLab JH validation 프로젝트 토큰입니다.

as-if-JH 브랜치 생성 방법#

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

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

의존성 변경이 없으면 이 프로세스를 실행하지 않습니다.

as-if-JH 파이프라인 트리거 및 실행 방법#

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

GitLab JH mirror 프로젝트 설정 방법#

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

GitLab JH에서 풀 미러링하며, 모든 브랜치를 미러링하고, 발산된 refs를 재정의하며, 미러가 업데이트될 때 파이프라인을 트리거하지 않습니다.

풀링 사용자는 프로젝트에서 maintainer인 @gitlab-jh-validation-bot입니다. 자격 증명은 1password 엔지니어링 볼트에서 찾을 수 있습니다.

GitLab JH는 공개 프로젝트이므로 미러링에 비밀번호를 사용하지 않습니다.

GitLab JH validation 프로젝트 설정 방법#

이 GitLab JH validation 프로젝트는 공개이며 CI가 활성화되어 있고 임시 프로젝트 변수가 설정되어 있습니다.

GitLab JH mirror에서 풀 미러링하며, 특정 브랜치 (master|main-jh)를 미러링하고, 발산된 refs를 재정의하며, 미러가 업데이트될 때 파이프라인을 트리거하지 않습니다.

풀링 사용자는 프로젝트의 maintainer이자 GitLab JH mirror의 maintainer인 @gitlab-jh-validation-bot입니다. 자격 증명은 1password 엔지니어링 볼트에서 찾을 수 있습니다.

GitLab JH mirror에서 변경 사항을 풀하기 위한 비밀번호로 write_repository 권한을 가진 @gitlab-jh-validation-bot의 개인 액세스 토큰을 사용합니다. 사용자 이름은 gitlab-jh-validation-bot으로 설정되어 있습니다.

또한 매일 실행되는 변수 SCHEDULE_TYPE이 maintenance로 설정된 파이프라인 스케줄이 있어 캐시를 업데이트하는 유지 관리 파이프라인을 실행합니다.

기본 CI/CD 구성 파일도 jh/.gitlab-ci.yml로 설정되어 있어 GitLab JH와 정확히 동일하게 실행됩니다.

또한 특별 브랜치 as-if-jh-code-sync 가 설정되고 보호됩니다. Maintainer는 푸시할 수 있고 개발자는 이 브랜치에서 병합할 수 있습니다. 개발자가 이 브랜치에 대한 파이프라인을 트리거할 수 있도록 허용해야 하기 때문입니다. 이것은 Developer 수준 사용자가 더 이상 보호된 브랜치에서 파이프라인을 실행할 수 없음을 해결하기 전까지의 타협안입니다.

머지 리퀘스트가 의존성을 변경했을 때 의존성을 동기화하기 위해 sync-as-if-jh-branch를 실행하는 데 사용됩니다. 구현에 대해서는 as-if-JH 브랜치 생성 방법을 참조하세요.

임시 GitLab JH validation 프로젝트 변수

• BUNDLER_CHECKSUM_VERIFICATION_OPT_IN이 false로 설정됩니다.

JiHu에서 jh/Gemfile.checksum이 커밋된 후 이 변수를 제거할 수 있습니다. 더 많은 컨텍스트는 다음에서 확인할 수 있습니다: 건너뛰기 위해 false로 설정

미러 프로젝트와 검증 프로젝트 모두 갖는 이유#

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

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

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

비용: 각 머지 리퀘스트에서 JiHuLab.com에 연결하고 싶지 않습니다. JiHuLab.com에서 GitLab.com의 어딘가로 코드를 미러링하고 머지 리퀘스트가 거기서 코드를 가져오는 것이 더 비용 효율적입니다. 이는 검증 프로젝트가 JiHuLab.com 대신 미러에서 코드를 가져올 수 있음을 의미합니다. 미러 프로젝트는 주기적으로 JiHuLab.com에서 가져옵니다.

브랜치 분리/보안/효율성: 모든 브랜치를 미러링하여 JiHuLab.com에서 해당 JH 브랜치를 가져올 수 있도록 하고 싶습니다. 하지만 검증 파이프라인을 제어하고 AS_IF_JH_TOKEN에 액세스할 수 있는 as-if-jh-code-sync 브랜치를 검증 프로젝트에서 덮어쓰고 싶지 않습니다. 그러나 단 하나의 브랜치를 제외하고 모든 브랜치를 미러링할 수는 없습니다. 자세한 내용은 이 이슈를 참조하세요.

이 이슈를 감안하여 검증 프로젝트는 master와 main-jh만 미러링하도록 설정되어 있습니다. 기술적으로는 이 브랜치가 필요하지 않지만, 머지 리퀘스트에서 변경 사항을 푸시할 때 머지 리퀘스트의 변경 사항만 푸시하면 되어 더 효율적이므로 리포지터리를 모든 기본 브랜치로 최신 상태를 유지하고 싶습니다.

관심사 분리:

검증 프로젝트에는 다음 브랜치만 있습니다:

변경 사항을 최신 상태로 유지하기 위한 master 및 main-jh.

• 의존성 동기화를 위한 as-if-jh-code-sync. 절대 미러링해서는 안 됩니다.

• 머지 리퀘스트의 as-if-jh/* 브랜치. 절대 미러링해서는 안 됩니다.

• 미러 프로젝트의 모든 브랜치는 JiHuLab.com에서 가져옵니다. 미러 프로젝트에는 아무것도 푸시하지 않으며, 파이프라인도 실행하지 않습니다. 미러 프로젝트에서는 CI/CD가 비활성화되어 있습니다.

이러한 이유들이 더 이상 문제가 되지 않는다면 설정과 프로세스를 단순화하기 위해 두 프로젝트를 병합하는 것을 고려할 수 있습니다.

rspec:undercoverage job#

rspec:undercoverage job은 undercover를 실행하여 머지 리퀘스트에 도입된 변경 사항 중 커버리지가 0인 항목을 감지하고 실패를 유발합니다.

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

rspec:undercoverage job이 EE에서 CE 메서드가 재정의됨으로 인해 누락된 커버리지를 감지하면 머지 리퀘스트에 pipeline:run-as-if-foss 라벨을 추가하고 새 파이프라인을 시작하세요.

긴급 상황이나 이 job에서 거짓 양성이 발생한 경우, 머지 리퀘스트에 pipeline:skip-undercoverage 라벨을 추가하여 이 job이 실패할 수 있도록 허용하세요.

rspec:undercoverage 실패 문제 해결#

먼저 rspec:coverage job의 gitlab.lcov 아티팩트에서 커버리지 데이터를 검토하세요. rspec:coverage job이 다양한 이유로 커버리지 데이터 수집에 실패했을 수 있습니다.

rspec:undercoverage job이 메서드 호출에 대한 커버리지 부족을 감지하지만 경고를 표시하지 않을 수 있습니다.

loc: app/controllers/projects/attestations_controller.rb:84:102, coverage: 87.5%
  def parsed_attestation_file hits: n/a
    @parsed_attestation_file ||= begin hits: 52
      if attestation && attestation_file hits: 12 branches: 1/1
        Gitlab::Json.parse(attestation_file.read) hits: 10
      else hits: n/a
        {} hits: 2
      end hits: n/a
    rescue JSON::ParserError => e hits: n/a
      Gitlab::AppJsonLogger.error( hits: 2
        message: 'Failed to parse attestation file', hits: n/a
        error_class: e.class.name, hits: n/a
        error_message: e.message, hits: n/a
        attestation_id: attestation&.id, hits: n/a
        project_id: project.id, hits: n/a
        feature_category: 'artifact_security' hits: n/a
      ) hits: n/a
      {} hits: 2
    end hits: n/a
  end hits: n/a

rspec:undercoverage job에는 거짓 양성 실패를 유발할 수 있는 알려진 버그가 있습니다. 너무 오래된 데이터베이스 마이그레이션을 업데이트하는 경우에도 그러한 거짓 양성 실패가 발생할 수 있습니다. pipeline:skip-undercoverage를 안전하게 적용할 수 있는지 확인하기 위해 로컬에서 커버리지를 테스트할 수 있습니다. 예를 들어 <spec>을 실패를 유발하는 테스트 이름으로 사용합니다:

• RUN_ALL_MIGRATION_TESTS=1 SIMPLECOV=1 bundle exec rspec <spec>을 실행합니다.

• scripts/undercoverage를 실행합니다.

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

관련 없는 파이프라인 실패를 우회하기 위해 pipeline:skip-undercoverage를 사용해야 하는 경우, 필요한 테스트 커버리지를 추가하는 후속 MR을 열어 주세요. 이렇게 하면 다른 사람들을 위해 시스템을 더 나은 상태로 유지할 수 있습니다.

pajamas_adoption job#

히스토리

• GitLab 16.8에서 도입됨.

pajamas_adoption job은 머지 리퀘스트에서 Pajamas Adoption Scanner를 실행하여 Pajamas Design System 채택의 퇴보를 방지합니다.

스캐너가 머지 리퀘스트로 인한 퇴보를 감지하면 job이 실패합니다. 머지 리퀘스트에서 퇴보를 수정할 수 없는 경우, 머지 리퀘스트에 pipeline:skip-pajamas-adoption 라벨을 추가한 후 job을 재시도하세요.

테스트 스위트 병렬화#

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

• prepare Stage의 retrieve-tests-metadata job이 knapsack/report-master.json 파일을 확보합니다:

knapsack/report-master.json 파일은 update-tests-metadata를 실행하는 최신 main 파이프라인(현재는 2시간마다 실행되는 maintenance 예약 master 파이프라인)에서 가져오며, 파일이 없으면 {}으로 초기화합니다.

• 각 [rspec|rspec-ee] [migration|unit|integration|system|geo] n m job은 knapsack rspec으로 실행되며 균등하게 분산된 테스트 공유를 가져야 합니다:

"이전 모든 Stage의 아티팩트가 기본적으로 전달"되므로 job이 knapsack/report-master.json에 액세스할 수 있기 때문에 작동합니다.

• job들은 자체 리포트 경로를 "knapsack/${TEST_TOOL}_${TEST_LEVEL}_${DATABASE}_${CI_NODE_INDEX}_${CI_NODE_TOTAL}_report.json"으로 설정합니다.

• knapsack이 제대로 작동하면 실행되는 테스트 파일이 Leftover specs가 아닌 Report specs 아래에 나열되어야 합니다.

• update-tests-metadata job(예약된 파이프라인에서만 실행되며, canonical 프로젝트에서 knapsack/report-master.json을 2가지 방법으로 업데이트합니다:

기본적으로 모든 knapsack/rspec*.json 파일을 가져와서 아티팩트로 저장된 단일 knapsack/report-master.json 파일로 병합합니다.

• (실험적) AVERAGE_KNAPSACK_REPORT 환경 변수가 true로 설정되면, 리포트를 병합하는 대신 job이 knapsack/report-master.json과 knapsack/rspec*.json 간의 테스트 지속 시간 평균을 계산하여 스펙 순서, 러너 하드웨어 차이, 플레이키 테스트 등 잠재적으로 무작위적인 요소의 성능 영향을 줄입니다. 이 실험적 접근 방식은 각 스펙 파일의 지속 시간을 더 잘 예측하여 병렬 job 간에 부하를 균등하게 분산시키고 job이 거의 동시에 완료될 수 있도록 하는 것을 목표로 합니다.

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

코드 커버리지#

테스트 선택, 커버리지 분석, 플레이키 테스트 분석을 위해 테스트 스위트에서 코드 커버리지 데이터를 수집합니다.

커버리지 유형#

CI job#

커버리지 데이터는 여러 CI job을 통해 흐릅니다:

수집: 테스트가 커버리지 계측과 함께 실행됩니다.

rspec job이 SimpleCov를 통해 백엔드 커버리지를 수집합니다.

• jest job이 Istanbul을 통해 프론트엔드 커버리지를 수집합니다.

• e2e:test-on-gdk가 Coverband(백엔드)와 Istanbul(프론트엔드)을 통해 E2E 커버리지를 수집합니다.

• workhorse job이 Go 커버리지를 수집합니다.

병합: 병렬 job과 E2E의 커버리지가 병합됩니다.

rspec:coverage가 RSpec 커버리지를 coverage/lcov/gitlab.lcov로 병합합니다.

• coverage-frontend가 Jest 커버리지를 병합합니다.

• 병합 스크립트가 E2E 커버리지와 단위/통합 커버리지를 결합합니다.

내보내기: 병합된 커버리지가 ClickHouse로 내보내집니다.

test-coverage:export-rspec-and-e2e가 백엔드 커버리지를 내보냅니다.

• test-coverage:export-jest-and-e2e가 프론트엔드 커버리지를 내보냅니다.

• test-coverage:export-workhorse가 Workhorse 커버리지를 내보냅니다.

커버리지 수집, 데이터 흐름, ClickHouse 스토리지에 대한 자세한 문서는 코드 커버리지를 참조하세요.

플레이키 테스트 재시도 및 격리#

실패한 테스트 자동 재시도#

실패한 백엔드 테스트는 별도의 RSpec 프로세스에서 한 번 자동으로 재시도됩니다. 이는 동일한 커밋 SHA로 실패한 후 통과하는 테스트로 정의되는 플레이키 테스트를 감지하는 데 도움이 됩니다.

"새 RSpec 프로세스에서 실패한 테스트 재시도"는 $RETRY_FAILED_TESTS_IN_NEW_PROCESS 변수를 false로 설정하여 비활성화할 수 있습니다.

격리된 테스트#

GitLab CI 파이프라인은 빠른 격리를 사용하여 조사 중에 파이프라인을 차단하는 테스트를 건너뜁니다.

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

격리 절차 및 구문은 테스트 격리 및 격리 프로세스 핸드북을 참조하세요.

호환성 테스트#

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

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

이 일반 가이드라인의 예외는 합리적인 이유가 있어야 하며 문서화되어야 합니다.

Ruby 버전 테스트#

GitLab.com과 기본 브랜치에서 Ruby 3.3을 실행하고 있습니다. 다음 Ruby 버전을 준비하기 위해 Ruby 3.4로 머지 리퀘스트를 실행합니다. 자세한 내용은 Ruby 3.4 에픽의 로드맵을 참조하세요.

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

머지 리퀘스트의 경우 다음 라벨을 추가하여 해당 Ruby 버전만 실행할 수 있습니다:

• pipeline:run-in-ruby3_3

PostgreSQL 버전 테스트#

테스트 스위트는 GitLab.com이 PostgreSQL 16에서 실행되고 Omnibus가 새 설치 및 업그레이드 시 PG14를 기본값으로 사용하므로 PostgreSQL 16을 기준으로 실행됩니다.

야간 예약 파이프라인에서 PostgreSQL 16, 17, 18에 대해 테스트 스위트를 실행합니다.

PG17 추가로 인해 파이프라인당 2000개 job 중 1946개로 야간 job 한도에 근접해 있습니다. 새 job 패밀리를 추가하면 야간 파이프라인이 실패할 수 있습니다.

현재 버전 테스트#

다음 Ruby 버전 테스트를 위해 ruby-next 브랜치에서 2시간마다 유지 관리 예약 파이프라인을 실행합니다. ruby-next에는 변경 사항이 없어야 합니다. 이 브랜치는 예약된 유지 관리 파이프라인에서 다른 Ruby 버전으로 파이프라인을 실행하기 위해서만 존재합니다.

ruby-sync 브랜치#

ruby-sync 브랜치는 ruby-next 및 rails-next 브랜치를 master와 최신 상태로 유지합니다. 이것은 고아 브랜치(orphan branch, master에서 파생되지 않음)로 자체 .gitlab-ci.yml, scripts/slack 헬퍼, README.md만 포함합니다.

예약 파이프라인이 ruby-sync에서 2시간마다 실행됩니다. gitlab job은:

• 전체 gitlab-org/gitlab 리포지터리를 클론합니다.

• ruby-next와 rails-next 각각에 대해: 브랜치를 체크아웃하고, origin/master를 병합한 후 결과를 푸시합니다.

이 푸시로 다운스트림 파이프라인이 트리거되지 않습니다. ruby-next 및 rails-next 브랜치는 독립적으로 자체 예약 유지 관리 파이프라인을 실행합니다.

인증#

gitlab job은 write_repository 범위와 Maintainer 권한을 가진 프로젝트 토큰(RUBY_SYNC_TOKEN)으로 인증합니다. 토큰은 ruby-sync 브랜치의 파이프라인 스케줄 변수에 저장됩니다.

재시도 및 실패 알림#

gitlab job은 일시적인 오류를 처리하기 위해 스크립트 실패 시 한 번 재시도합니다. 여전히 실패하면 notify job이 CI_SLACK_WEBHOOK_URL을 통해 #backend Slack 채널(ruby-sync 사용자 이름)에 메시지를 보냅니다:

☠️ ruby-sync failed to merge master into the ruby-next/rails-next branches
in gitlab-org/gitlab. Pipeline: <pipeline_url> — Docs: <docs_url>

ruby-sync 실패 문제 해결#

일반적인 실패 원인:

• 일시적인 GitLab 부하 오류: job이 전체 리포지터리를 클론하므로 높은 부하 기간에 실패할 수 있습니다. 실패한 파이프라인을 재시도하세요.

• 병합 충돌: ruby-next 또는 rails-next가 충돌을 일으키는 방식으로 master에서 분기된 경우 git merge 단계가 실패합니다. 영향받은 브랜치에서 수동으로 충돌을 해결하고 재시도하세요.

• 인증 오류: RUBY_SYNC_TOKEN 프로젝트 토큰이 만료되지 않았는지 확인하세요. 파이프라인 스케줄 구성을 확인하세요.

재시도하려면 파이프라인 스케줄 페이지로 이동하여 ruby-sync 스케줄을 실행하거나 파이프라인 페이지에서 실패한 job을 재시도하세요.

Redis 버전 테스트#

테스트 스위트는 기본적으로 GitLab 설치에 권장되는 버전인 Redis 7.2를 기준으로 실행됩니다. 주간 예약 파이프라인은 지원 범위 전반의 호환성을 검증하기 위해 Redis 7.0(최소 버전) 및 Valkey 7.2에 대해서도 실행됩니다.

현재 버전 테스트#

단일 데이터베이스 테스트#

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

야간 예약 파이프라인과 데이터베이스 관련 파일을 수정하는 머지 리퀘스트에서도 단일 데이터베이스로 테스트를 실행합니다.

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

• 하나의 연결을 사용하는 단일 데이터베이스. GitLab이 하나의 연결 풀을 사용하여 모든 테이블에 연결합니다. -single-db로 끝나는 모든 job을 통해 실행됩니다.

• 두 개의 연결을 사용하는 단일 데이터베이스. GitLab이 서로 다른 데이터베이스 연결을 사용하여 gitlab_main, gitlab_ci 데이터베이스 테이블에 연결합니다. -single-db-ci-connection으로 끝나는 모든 job을 통해 실행됩니다.

단일 데이터베이스로 테스트를 강제로 실행하려면 머지 리퀘스트에 pipeline:run-single-db 라벨을 추가할 수 있습니다.

Elasticsearch 및 OpenSearch 버전 테스트#

특정 조건이 충족되면 GitLab.com이 Elasticsearch 9에서 실행되므로 테스트 스위트는 Elasticsearch 9를 기준으로 실행됩니다.

야간 예약 파이프라인에서 Elasticsearch 8, 9 및 OpenSearch 1, 2에 대해 테스트 스위트를 실행합니다. 모든 테스트 스위트는 데이터베이스와 검색 백엔드 간에 의존성이 없으므로 PostgreSQL 17을 사용합니다.

모니터링#

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

로깅#

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

CI 구성 내부#

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

성능#

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

---

개발 문서로 돌아가기