跳至主要内容

持续集成检查

当你提交拉取请求时，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 选项，搜索 cmake。使用这些选项并遵循 通用构建过程。

报告详细信息​

  • 编译器：clang-18，可选地带目标平台名称
  • 构建类型：Debug 或 RelWithDebInfo (cmake)。
  • 消毒器：none（无消毒器）、address (ASan)、memory (MSan)、undefined (UBSan) 或 thread (TSan)。
  • 状态：success 或 fail
  • 构建日志：指向构建和文件复制日志的链接，在构建失败时很有用。
  • 构建时间.
  • 工件：构建结果文件（其中 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-18 --debug-build --clang-tidy

功能无状态测试​

为在各种配置（发布版、调试版、带消毒器等）中构建的 ClickHouse 二进制文件运行 无状态功能测试。查看报告以查看哪些测试失败，然后按照 此处 所述在本地重现故障。注意，你必须使用正确的构建配置才能重现 - 测试在 AddressSanitizer 下可能失败，但在 Debug 中则通过。从 CI 构建检查页面 下载二进制文件，或在本地构建。

功能有状态测试​

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

集成测试​

运行 集成测试。

Bugfix 验证检查​

检查是否添加了新的测试（功能性或集成性）或存在一些更改的测试，它们在使用 master 分支构建的二进制文件时会失败。当拉取请求带有 "pr-bugfix" 标签时，将触发此检查。

压力测试​

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

* Fix all other test failures first;
* Look at the report to find the server logs and check them for possible causes
  of error.

兼容性检查​

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

AST 模糊测试​

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

性能测试​

衡量查询性能的变化。这是最长的检查，运行时间不到 6 小时。性能测试报告在 此处 有详细介绍。