Continuous Integration Checks

    If it looks like the check failure is not related to your changes, it may be
    some transient failure or an infrastructure problem. Push an empty commit to
    the pull request to restart the CI checks:

    If you are not sure what to do, ask a maintainer for help.

    Verifies that the PR can be merged to master. If not, it will fail with the
    message ‘Cannot fetch mergecommit’. To fix this check, resolve the conflict as
    described in the ,
    or merge the master branch to your pull request branch using git.

    Docs check

    Tries to build the ClickHouse documentation website. It can fail if you changed
    something in the documentation. Most probable reason is that some cross-link in
    the documentation is wrong. Go to the check report and look for ERROR and WARNING messages.

    Description Check

    Check that the description of your pull request conforms to the template
    PULL_REQUEST_TEMPLATE.md.
    You have to specify a changelog category for your change (e.g., Bug Fix), and
    write a user-readable message describing the change for

    Push To Dockerhub

    Builds docker images used for build and tests, then pushes them to DockerHub.

    Marker Check

    This check means that the CI system started to process the pull request. When it has ‘pending’ status, it means that not all checks have been started yet. After all checks have been started, it changes status to ‘success’.

    Style Check

    Performs some simple regex-based checks of code style, using the binary (note that it can be run locally).
    If it fails, fix the style errors following the code style guide.

    • output.txt contains the check resulting errors (invalid tabulation etc), blank page means no errors. Successful result example.
    • test_run.txt.out.log contains the building and analyzing log file. It includes only parsing or not-found errors.
    • HTML report contains the analysis results. For its description visit PVS’s official site.

    Fast Test

    Normally this is the first check that is ran for a PR. It builds ClickHouse and
    runs most of stateless functional tests, omitting
    some. If it fails, further checks are not started until it is fixed. Look at
    the report to see which tests fail, then reproduce the failure locally as
    described .

    Status page example

    Status Page Files

    • runlog.out.log is the general log that includes all other logs.
    • test_log.txt
    • submodule_log.txt contains the messages about cloning and checkouting needed submodules.
    • stderr.log
    • stdout.log
    • clickhouse-server.log
    • clone_log.txt
    • install_log.txt
    • clickhouse-server.err.log
    • build_log.txt
    • contains messages about the C/C++ and Linux flags check.

    Status Page Columns

    • Test status — one of Skipped, Success, or Fail.
    • Test time, sec. — empty on this test.

    Build Check

    Builds ClickHouse in various configurations for use in further steps. You have to fix the builds that fail. Build logs often has enough information to fix the error, but you might have to reproduce the failure locally. The cmake options can be found in the build log, grepping for cmake. Use these options and follow the general build process.

    .

    • Compiler: gcc-9 or clang-10 (or clang-10-xx for other architectures e.g. clang-10-freebsd).
    • Build type: Debug or RelWithDebInfo (cmake).
    • Sanitizer: none (without sanitizers), address (ASan), memory (MSan), undefined (UBSan), or thread (TSan).
    • Bundled: bundled build uses libraries from contrib folder, and unbundled build uses system libraries.
    • Splitted splitted is a split build
    • Status: success or
    • Build log: link to the building and files copying log, useful when build failed.
    • Build time.
    • Artifacts: build result files (with XXX being the server version e.g. 20.8.1.4344).
      • clickhouse-client_XXX_all.deb
      • clickhouse-common-static-dbg_XXX[+asan, +msan, +ubsan, +tsan]_amd64.deb
      • clickhouse-common-staticXXX_amd64.deb
      • clickhouse-server_XXX_all.deb
      • clickhouse-test_XXX_all.deb
      • clickhouse_XXX_amd64.buildinfo
      • clickhouse_XXX_amd64.changes
      • clickhouse: Main built binary.
      • clickhouse-odbc-bridge
      • unit_tests_dbms: GoogleTest binary with ClickHouse unit tests.
      • shared_build.tgz: build with shared libraries.

    Special Build Check

    Performs static analysis and code style checks using clang-tidy. The report is similar to the build check. Fix the errors found in the build log.

    Functional Stateless Tests

    Runs stateless functional tests for ClickHouse
    binaries built in various configurations — release, debug, with sanitizers,
    etc. Look at the report to see which tests fail, then reproduce the failure
    locally as described . Note that you
    have to use the correct build configuration to reproduce — a test might fail
    under AddressSanitizer but pass in Debug. Download the binary from CI build
    checks page    , or build it locally.

    Functional Stateful Tests

    Runs stateful functional tests. Treat them in the same way as the functional stateless tests. The difference is that they require hits and visits tables from the to run.

    Runs integration tests.

    Testflows Check

    Stress Test

    Runs stateless functional tests concurrently from several clients to detect
    concurrency-related errors. If it fails:

    Split Build Smoke Test

    Checks that the server build in split build
    configuration can start and run simple queries. If it fails:

    Compatibility Check

    Checks that clickhouse binary runs on distributions with old libc versions. If it fails, ask a maintainer for help.

    AST Fuzzer

    Runs randomly generated queries to catch program errors. If it fails, ask a maintainer for help.

    Measure changes in query performance. This is the longest check that takes just below 6 hours to run. The performance test report is described in detail .

    QA

    It’s a link to the Yandex’s internal job system. Yandex employees can see the check’s start time and its more verbose status.

    Where the tests are run