can be tested 레이블을 추가하면 진행됩니다.
검사 결과는 GitHub checks documentation에 설명된 대로 GitHub 풀 리퀘스트 페이지에 표시됩니다.
검사가 실패하면 수정이 필요할 수 있습니다.
이 페이지에서는 마주칠 수 있는 검사를 개괄적으로 설명하고, 이를 해결하기 위해 수행할 수 있는 작업을 안내합니다.
검사 실패가 변경 사항과 관련이 없어 보인다면, 일시적인 실패이거나 인프라 문제일 수 있습니다.
풀 리퀘스트에 빈 커밋을 푸시하여 CI 검사를 다시 시작하십시오:
master와 머지
Cannot fetch mergecommit 메시지와 함께 실패합니다.
이 검사를 통과하려면 GitHub 문서에 설명된 대로 충돌을 해결하거나, git을 사용해 master 브랜치를 pull request 브랜치에 머지하십시오.
문서 검사
ERROR 및 WARNING 메시지를 확인하십시오.
설명 검사
Docker 이미지
공식 Docker 라이브러리 테스트
clickhouse/clickhouse-server Docker 이미지가 올바르게 동작하는지 확인합니다.
새 테스트를 추가하려면 디렉터리 ci/jobs/scripts/docker_server/tests/$test_name를 만들고 그 안에 run.sh 스크립트를 생성하십시오.
테스트에 대한 추가 정보는 CI jobs scripts 문서에서 확인할 수 있습니다.
Marker 검사
스타일 검사
cpp
ci/jobs/scripts/check_style/check_cpp.sh 스크립트를 사용해 간단한 정규식 기반 code style 검사를 수행합니다(로컬에서도 실행할 수 있습니다).
검사에 실패하면 코드 스타일 가이드에 따라 스타일 문제를 수정하세요.
codespell, aspell
mypy
로컬에서 Style Check 작업 실행하기
clickhouse/style-test Docker 이미지를 가져와 컨테이너화된 환경에서 작업을 실행합니다.
Python 3와 Docker 외에는 별도의 종속성이 필요하지 않습니다.
stateless tests 실행하기
사전 요구 사항
- Python 3 (표준 라이브러리만)
- Docker
CI 작업을 로컬에서 실행하기
job 이름을 선택한 다음 로컬에서 실행하십시오:
- 항상 CI 보고서에 표시된 작업 이름을 그대로 정확히 따옴표로 묶어 사용하십시오(공백과 쉼표가 포함될 수 있음). 예:
"Stateless tests (amd_debug, parallel)". 이렇게 하면 CI와 동일한 ClickHouse 구성이 설정되고 동일한 테스트가 실행됩니다. - 작업 이름에 포함된 아키텍처와 빌드 유형(예:
amd_debug)은 CI 전용 레이블입니다. 로컬에서 실행할 때는 영향을 주지 않습니다. 즉, 현재 실행 중인 아키텍처와 제공한 바이너리가 무엇이든 작업은 그것을 사용합니다. 작업 이름은 ClickHouse 구성과 테스트 세트만 결정합니다(--test로 재정의하지 않는 한). - CI에서는 리소스를 더 효율적으로 활용하기 위해 기능 테스트를 여러 배치로 나누어 실행합니다. 예를 들어
"Stateless tests (amd_debug, parallel)"와"Stateless tests (amd_debug, sequential)"를 함께 실행하면 전체 범위를 포괄합니다. 병렬 실행이 안전한 테스트는 동시에 실행되고, 나머지는 순차적으로 실행됩니다. 이렇게 분할하면 가능한 범위에서 병렬성을 극대화하여 전체 CI 시간을 줄일 수 있습니다. 로컬에서 전체 테스트 범위를 재현하려면 두 배치를 모두 실행하십시오. - 제한된 범위의 기능 테스트를 실행해 ClickHouse의 기본 기능을 검증하는
"Fast test"CI 작업도 있습니다. 이 작업은 모든 선택적 모듈이 포함되지 않은 빌드를 사용하며, 회귀를 가장 빠르게 찾아내는 방법입니다. 로컬에서도 같은 방식으로 실행할 수 있습니다. ClickHouse 바이너리를 기본 검색 경로 중 하나(./ci/tmp/clickhouse,./build/programs/clickhouse, 또는./clickhouse)에 두십시오. 그렇지 않으면 작업이 먼저 ClickHouse를 빌드하려고 시도합니다:
CI 작업 내에서 특정 테스트 실행
--test를 사용하면 CI에서 사용하는 것과 동일한 ClickHouse 구성을 준비한 뒤, 선택한 테스트만 실행합니다:
- 여러 테스트 이름을 지정할 수 있습니다:
- 팁: ClickHouse 구성은 아무 것이나 상관없고 특정 테스트만 실행하면 되는 경우, 전체 작업 이름 대신 별칭
functional을 사용하세요:
추가 사용자 설정 옵션
--path PATH— ClickHouse 실행 파일의 사용자 지정 경로입니다. 기본적으로 러너는./ci/tmp/clickhouse,./build/programs/clickhouse,./clickhouse순서대로 검색합니다.--count N— 각 테스트를 N번 반복합니다.--workers N— 머신 용량을 기준으로 자동 계산되는 병렬 워커 수를 재정의합니다.
빌드 검사
로컬에서 빌드 실행하기
사용 가능한 빌드 작업
Build (amd_debug)- 심볼이 포함된 디버그 빌드Build (amd_release)- 최적화된 릴리스 빌드Build (amd_asan)- Address Sanitizer 빌드Build (amd_tsan)- Thread Sanitizer 빌드Build (amd_msan)- Memory Sanitizer 빌드Build (amd_ubsan)- Undefined Behavior Sanitizer 빌드Build (amd_binary)- Thin LTO 없이 빠르게 생성하는 릴리스 빌드Build (amd_compat)- 구형 시스템용 호환성 빌드Build (amd_musl)- musl libc를 사용한 빌드Build (amd_darwin)- macOS 빌드Build (amd_freebsd)- FreeBSD 빌드
Build (arm_release)- ARM64용 최적화 릴리스 빌드Build (arm_asan)- ARM64 Address Sanitizer 빌드Build (arm_coverage)- 커버리지 계측이 포함된 ARM64 빌드Build (arm_binary)- Thin LTO 없이 빠르게 생성하는 ARM64 릴리스 빌드Build (arm_darwin)- macOS ARM64 빌드Build (arm_v80compat)- ARMv8.0 호환성 빌드
Build (ppc64le)- PowerPC 64비트 리틀 엔디안Build (riscv64)- RISC-V 64비트Build (s390x)- IBM System/390 64비트Build (loongarch64)- LoongArch 64비트
<repo_root>/ci/tmp/build 디렉터리에서 확인할 수 있습니다.
참고: “기타 아키텍처” 범주에 속하지 않는 빌드에는 교차 컴파일이 사용되므로, BUILD_JOB_NAME에서 요청한 빌드를 생성하려면 로컬 머신의 아키텍처가 빌드 유형과 일치해야 합니다.
예시
상태 비저장 기능 테스트
통합 테스트
버그 수정 검증 검사
스트레스 테스트
- 먼저 다른 테스트 실패를 모두 해결하십시오;
- 보고서에서 서버 로그를 찾아 오류의 가능한 원인을 확인하십시오.
호환성 검사
clickhouse 실행 파일이 실행되는지 확인합니다.
실패하면 메인테이너에게 도움을 요청하십시오.