跳转到主要内容
跳转到主要内容
编辑此页

持续集成 (CI)

当您提交拉取请求时，ClickHouse 持续集成 (CI) 系统 会对您的代码运行一些自动化检查。这发生在仓库维护者（ClickHouse 团队的成员）审查了您的代码并将 can be tested 标签添加到您的拉取请求之后。检查结果在 GitHub 拉取请求页面上列出，如 GitHub 检查文档 中所述。如果检查失败，您可能需要修复它。此页面概述了您可能遇到的检查，以及您可以采取哪些措施来修复它们。

如果检查失败看起来与您的更改无关，则可能是某些瞬时故障或基础设施问题。向拉取请求推送一个空提交以重新启动 CI 检查

git reset
git commit --allow-empty
git push

如果您不确定该怎么做，请向维护者寻求帮助。

与 Master 分支合并​

验证 PR 是否可以合并到 master 分支。如果不能，它将失败并显示消息 Cannot fetch mergecommit。要修复此检查，请按照 GitHub 文档 中所述解决冲突，或者使用 git 将 master 分支合并到您的拉取请求分支。

文档检查​

尝试构建 ClickHouse 文档网站。如果您更改了文档中的某些内容，则可能会失败。最可能的原因是文档中的某些交叉链接不正确。转到检查报告并查找 ERROR 和 WARNING 消息。

描述检查​

检查您的拉取请求的描述是否符合模板 PULL_REQUEST_TEMPLATE.md。您必须为您的更改指定一个更新日志类别（例如，Bug 修复），并编写一条用户可读的消息来描述 CHANGELOG.md 的更改

推送到 DockerHub​

构建用于构建和测试的 Docker 镜像，然后将它们推送到 DockerHub。

标记检查​

此检查表示 CI 系统已开始处理拉取请求。当它处于“pending”状态时，表示并非所有检查都已启动。在所有检查都启动后，它会将状态更改为“success”。

风格检查​

使用 utils/check-style/check-style 二进制文件（请注意，它可以在本地运行）执行一些基于正则表达式的的代码风格检查。如果检查失败，请按照 代码风格指南 修复风格错误。

在本地运行风格检查：​

mkdir -p /tmp/test_output
# running all checks
python3 tests/ci/style_check.py --no-push

# run specified check script (e.g.: ./check-mypy)
docker run --rm --volume=.:/ClickHouse --volume=/tmp/test_output:/test_output -u $(id -u ${USER}):$(id -g ${USER}) --cap-add=SYS_PTRACE --entrypoint= -w/ClickHouse/utils/check-style clickhouse/style-test ./check-mypy

# find all style check scripts under the directory:
cd ./utils/check-style

# Check duplicate includes
./check-duplicate-includes.sh

# Check c++ formatting
./check-style

# Check python formatting with black
./check-black

# Check python type hinting with mypy
./check-mypy

# Check python with flake8
./check-flake8

# Check code with codespell
./check-typos

# Check docs spelling
./check-doc-aspell

# Check whitespaces
./check-whitespaces

# Check github actions workflows
./check-workflows

# Check submodules
./check-submodules

# Check shell scripts with shellcheck
./shellcheck-run.sh

快速测试​

通常，这是为 PR 运行的第一个检查。它构建 ClickHouse 并运行大多数 无状态功能测试，省略了一些。如果检查失败，则在修复之前不会启动进一步的检查。查看报告以查看哪些测试失败，然后按照 此处 所述在本地重现失败。

在本地运行快速测试：​

mkdir -p /tmp/test_output
mkdir -p /tmp/fasttest-workspace
cd ClickHouse
# this docker command performs minimal ClickHouse build and run FastTests against it
docker run --rm --cap-add=SYS_PTRACE -u $(id -u ${USER}):$(id -g ${USER})  --network=host -e FASTTEST_WORKSPACE=/fasttest-workspace -e FASTTEST_OUTPUT=/test_output -e FASTTEST_SOURCE=/ClickHouse --cap-add=SYS_PTRACE -e stage=clone_submodules --volume=/tmp/fasttest-workspace:/fasttest-workspace --volume=.:/ClickHouse --volume=/tmp/test_output:/test_output clickhouse/fasttest

状态页面文件​

  • runlog.out.log 是包含所有其他日志的通用日志。
  • test_log.txt
  • submodule_log.txt 包含有关克隆和检出所需子模块的消息。
  • stderr.log
  • stdout.log
  • clickhouse-server.log
  • clone_log.txt
  • install_log.txt
  • clickhouse-server.err.log
  • build_log.txt
  • cmake_log.txt 包含有关 C/C++ 和 Linux 标志检查的消息。

状态页面列​

  • 测试名称 包含测试的名称（不包含路径，例如，所有测试类型都将剥离为名称）。
  • 测试状态 -- 跳过、成功 或 失败 之一。
  • 测试时间，秒。 -- 此测试为空。

构建检查​

以各种配置构建 ClickHouse，以供后续步骤使用。您必须修复失败的构建。构建日志通常有足够的信息来修复错误，但您可能需要在本地重现失败。cmake 选项可以在构建日志中找到，grep cmake。使用这些选项并遵循 常规构建过程。

报告详情​

  • 编译器：clang-19，可选地带有目标平台名称
  • 构建类型：Debug 或 RelWithDebInfo (cmake)。
  • Sanitizer：none（不使用 Sanitizer）、address (ASan)、memory (MSan)、undefined (UBSan) 或 thread (TSan)。
  • 状态：success 或 fail
  • 构建日志：构建和文件复制日志的链接，在构建失败时很有用。
  • 构建时间.
  • Artifacts：构建结果文件（其中 XXX 是服务器版本，例如 20.8.1.4344）。
    • clickhouse-client_XXX_amd64.deb
    • clickhouse-common-static-dbg_XXX[+asan, +msan, +ubsan, +tsan]_amd64.deb
    • clickhouse-common-staticXXX_amd64.deb
    • clickhouse-server_XXX_amd64.deb
    • clickhouse：主构建二进制文件。
    • clickhouse-odbc-bridge
    • unit_tests_dbms：带有 ClickHouse 单元测试的 GoogleTest 二进制文件。
    • performance.tar.zst：用于性能测试的特殊包。

特殊构建检查​

使用 clang-tidy 执行静态分析和代码风格检查。报告类似于 构建检查。修复构建日志中发现的错误。

在本地运行 clang-tidy：​

有一个方便的 packager 脚本可以在 Docker 中运行 clang-tidy 构建

mkdir build_tidy
./docker/packager/packager --output-dir=./build_tidy --package-type=binary --compiler=clang-19 --debug-build --clang-tidy

功能无状态测试​

为以各种配置（release、debug、带有 sanitizer 等）构建的 ClickHouse 二进制文件运行 无状态功能测试。查看报告以查看哪些测试失败，然后按照 此处 所述在本地重现失败。请注意，您必须使用正确的构建配置来重现 - 测试可能在 AddressSanitizer 下失败，但在 Debug 下通过。从 CI 构建检查页面 下载二进制文件，或在本地构建它。

功能有状态测试​

运行 有状态功能测试。以与功能无状态测试相同的方式对待它们。不同之处在于它们需要来自 点击流数据集 的 hits 和 visits 表才能运行。

集成测试​

运行 集成测试。

Bugfix 验证检查​

检查是否有一个新的测试（功能测试或集成测试），或者是否有一些更改的测试在使用 master 分支上构建的二进制文件时失败。当拉取请求具有“pr-bugfix”标签时，将触发此检查。

压力测试​

从多个客户端并发运行无状态功能测试，以检测与并发相关的错误。如果它失败

  • 首先修复所有其他测试失败；
  • 查看报告以查找服务器日志，并检查它们是否存在可能的错误原因。

兼容性检查​

检查 clickhouse 二进制文件是否可以在具有旧 libc 版本的发行版上运行。如果它失败，请向维护者寻求帮助。

AST Fuzzer​

运行随机生成的查询以捕获程序错误。如果它失败，请向维护者寻求帮助。

性能测试​

测量查询性能的变化。这是最长的检查，需要不到 6 小时才能运行。性能测试报告在 此处 详细描述。