Тестирование ClickHouse

Функциональные тесты

Функциональные тесты — это самые простые и удобные в использовании. Большинство функций ClickHouse можно протестировать с помощью функциональных тестов, и их обязательно использовать для каждого изменения в коде ClickHouse, которое можно протестировать таким образом.

Каждый функциональный тест отправляет один или несколько запросов на работающий сервер ClickHouse и сравнивает результат с эталонным.

Тесты находятся в директории ./tests/queries.

Каждый тест может быть одного из двух типов: .sql и .sh.

• Тест .sql — это простой SQL-скрипт, который передается на clickhouse-client.
• Тест .sh — это скрипт, который запускается самостоятельно.

SQL-тесты, как правило, предпочительнее, чем тесты .sh. Вы должны использовать тесты .sh только тогда, когда необходимо протестировать какую-то функцию, которую нельзя протестировать с помощью чистого SQL, такую как передача некоторых входных данных в clickhouse-client или тестирование clickhouse-local.

примечание

Распространенная ошибка при тестировании типов данных DateTime и DateTime64 заключается в предположении, что сервер использует конкретный часовой пояс (например, "UTC"). Это не так, часовые пояса в CI-тестах преднамеренно рандомизируются. Самый простой способ обхода — явно указать часовой пояс для тестовых значений, например, toDateTime64(val, 3, 'Europe/Amsterdam').

Запуск теста локально

Запустите сервер ClickHouse локально, слушающий на порту по умолчанию (9000). Чтобы запустить, например, тест 01428_hash_set_nan_key, перейдите в папку репозитория и выполните следующую команду:

PATH=<path to clickhouse-client>:$PATH tests/clickhouse-test 01428_hash_set_nan_key

Результаты тестирования (stderr и stdout) записываются в файлы 01428_hash_set_nan_key.[stderr|stdout], которые расположены рядом с самим тестом (для queries/0_stateless/foo.sql вывод будет в queries/0_stateless/foo.stdout).

Смотрите tests/clickhouse-test --help для всех опций clickhouse-test. Вы можете запустить все тесты или запустить подмножество тестов, предоставив фильтр для названий тестов: ./clickhouse-test substring. Также есть опции для запуска тестов параллельно или в случайном порядке.

Добавление нового теста

Чтобы добавить новый тест, сначала создайте файл .sql или .sh в директории queries/0_stateless. Затем сгенерируйте соответствующий файл .reference, используя clickhouse-client < 12345_test.sql > 12345_test.reference или ./12345_test.sh > ./12345_test.reference.

Тесты должны только создавать, удалять, выбирать из и т.д. таблицы в базе данных test, которая автоматически создается заранее. Использование временных таблиц допускается.

Чтобы настроить такую же среду, как в CI локально, установите тестовые конфигурации (они будут использовать мок-реализацию Zookeeper и настраивать некоторые параметры)

cd <repository>/tests/config
sudo ./install.sh

примечание

Тесты должны быть

• минимальными: создавать только минимально необходимые таблицы, колонки и сложность,
• быстрыми: не занимать больше нескольких секунд (лучше менее секунды),
• корректными и детерминированными: давать сбой, если и только если тестируемая функция не работает,
• изолированными/статeless: не полагаться на окружение и тайминг,
• исчерпывающими: охватывать крайние случаи, такие как нули, нулевые значения, пустые множества, исключения (отрицательные тесты, используйте синтаксис -- { serverError xyz } и -- { clientError xyz } для этого),
• очищать таблицы в конце теста (в случае остаточных данных),
• убедиться, что другие тесты не тестируют одно и то же (т.е. сначала выполните grep).

Ограничение запусков тестов

Тест может иметь ноль или более тегов, указывающих на ограничения, в каких контекстах тест запускается в CI.

Для тестов .sql теги помещаются в первой строке в виде SQL-комментария:

-- Tags: no-fasttest, no-replicated-database
-- no-fasttest: <provide_a_reason_for_the_tag_here>
-- no-replicated-database: <provide_a_reason_here>

SELECT 1

Для тестов .sh теги записываются в виде комментария на второй строке:

#!/usr/bin/env bash

# Tags: no-fasttest, no-replicated-database

# - no-fasttest: <provide_a_reason_for_the_tag_here>

# - no-replicated-database: <provide_a_reason_here>

Список доступных тегов:

Имя тега	Что он делает	Пример использования
disabled	Тест не запускается
long	Время выполнения теста увеличено с 1 до 10 минут
deadlock	Тест запускается в цикле на долгое время
race	То же, что и deadlock. Предпочитайте deadlock
shard	Сервер должен слушать 127.0.0.*
distributed	То же, что и shard. Предпочитайте shard
global	То же, что и shard. Предпочитайте shard
zookeeper	Тест требует работы Зоопарка или ClickHouse Keeper	Тест использует ReplicatedMergeTree
replica	То же, что и zookeeper. Предпочитайте zookeeper
no-fasttest	Тест не запускается под Быстрым тестом	Тест использует движок таблиц MySQL, который отключен в Быстром тесте
fasttest-only	Тест запускается только под Быстрым тестом
no-[asan, tsan, msan, ubsan]	Отключает тесты в сборке с санитайзерами	Тест запускается под QEMU, который не работает с санитайзерами
no-replicated-database
no-ordinary-database
no-parallel	Запуск других тестов параллельно с этим отключен	Тест читает из таблиц system, и инварианты могут быть нарушены
no-parallel-replicas
no-debug
no-stress
no-polymorphic-parts
no-random-settings
no-random-merge-tree-settings
no-backward-compatibility-check
no-cpu-x86_64
no-cpu-aarch64
no-cpu-ppc64le
no-s3-storage

В дополнение к указанным выше настройкам, вы можете использовать флаги USE_* из system.build_options, чтобы определить использование определенных функций ClickHouse. Например, если ваш тест использует таблицу MySQL, вы должны добавить тег use-mysql.

Указание пределов для случайных настроек

Тест может указать минимальные и максимальные допустимые значения для настроек, которые могут быть рандомизированы во время выполнения теста.

Для тестов .sh пределы записываются в виде комментария на строке рядом с тегами или на второй строке, если тегов нет:

#!/usr/bin/env bash

# Tags: no-fasttest

# Random settings limits: max_block_size=(1000, 10000); index_granularity=(100, None)

Для тестов .sql теги помещаются как SQL-комментарий на строке рядом с тегами или в первой строке:

-- Tags: no-fasttest
-- Random settings limits: max_block_size=(1000, 10000); index_granularity=(100, None)
SELECT 1

Если вам нужно указать только один предел, вы можете использовать None для другого.

Выбор имени теста

Имя теста начинается с пятизначного префикса, за которым следует описательное имя, например, 00422_hash_function_constexpr.sql. Чтобы выбрать префикс, найдите наибольший префикс, уже присутствующий в директории, и увеличьте его на единицу.

ls tests/queries/0_stateless/[0-9]*.reference | tail -n 1

Тем временем могут быть добавлены некоторые другие тесты с тем же числовым префиксом, но это нормально и не приведет к проблемам, вам не нужно менять его позже.

Проверка возникновения ошибки, которая должна произойти

Иногда вам нужно протестировать, что на неправильный запрос возникает ошибка сервера. Мы поддерживаем специальные аннотации для этого в SQL-тестах, в следующей форме:

SELECT x; -- { serverError 49 }

Этот тест гарантирует, что сервер возвращает ошибку с кодом 49 о неизвестной колонке x. Если ошибки нет или ошибка отличается, тест завершится неудачно. Если вы хотите убедиться, что ошибка возникает на стороне клиента, используйте аннотацию clientError вместо.

Не проверяйте конкретную формулировку сообщения об ошибке, оно может измениться в будущем, и тест будет без необходимости ломаться. Проверяйте только код ошибки. Если существующий код ошибки недостаточно точен для ваших нужд, рассмотрите возможность добавления нового.

Тестирование распределенного запроса

Если вы хотите использовать распределенные запросы в функциональных тестах, вы можете использовать табличную функцию remote с адресами 127.0.0.{1..2} для того, чтобы сервер запрашивал сам себя; или вы можете использовать предопределенные тестовые кластеры в конфигурационном файле сервера, такие как test_shard_localhost. Не забудьте добавить слова shard или distributed к имени теста, чтобы он выполнялся в CI в правильных конфигурациях, где сервер настроен на поддержку распределенных запросов.

Работа с временными файлами

Иногда в тесте на шелле вам может потребоваться создать файл на лету для работы. Имейте в виду, что некоторые проверки CI запускают тесты параллельно, поэтому если вы создаете или удаляете временный файл в вашем сценарии без уникального имени, это может привести к сбоям некоторых CI проверок, таких как Flaky. Чтобы обойти это, вы должны использовать переменную окружения $CLICKHOUSE_TEST_UNIQUE_NAME, чтобы дать временным файлам имя, уникальное для выполняемого теста. Таким образом, вы можете быть уверены, что файл, который вы создаете во время настройки или удаляете во время очистки, является файлом, используемым только этим тестом, а не каким-либо другим тестом, который выполняется параллельно.

Известные ошибки

Если мы знаем о некоторых ошибках, которые можно легко воспроизвести с помощью функциональных тестов, мы помещаем подготовленные функциональные тесты в директорию tests/queries/bugs. Эти тесты будут перемещены в tests/queries/0_stateless, когда ошибки будут исправлены.

Интеграционные тесты

Интеграционные тесты позволяют тестировать ClickHouse в кластерной конфигурации и взаимодействие ClickHouse с другими серверами, такими как MySQL, Postgres, MongoDB. Они полезны для эмуляции сетевых разрывов, потерь пакетов и т.д. Эти тесты запускаются под Docker и создают несколько контейнеров с различным программным обеспечением.

Смотрите tests/integration/README.md о том, как запустить эти тесты.

Обратите внимание, что интеграция ClickHouse с сторонними драйверами не тестируется. Кроме того, в настоящее время у нас нет интеграционных тестов с нашими JDBC и ODBC драйверами.

Модульные тесты

Модульные тесты полезны, когда вы хотите протестировать не весь ClickHouse, а одну изолированную библиотеку или класс. Вы можете включать или отключать сборку тестов с помощью опции CMake ENABLE_TESTS. Модульные тесты (и другие тестовые программы) расположены в подкаталогах tests по всему коду. Чтобы запустить модульные тесты, наберите ninja test. Некоторые тесты используют gtest, но некоторые просто программы, которые возвращают ненулевой код выхода при ошибке теста.

Необязательно иметь модульные тесты, если код уже покрыт функциональными тестами (а функциональные тесты обычно гораздо проще использовать).

Вы можете запускать отдельные проверки gtest, вызывая исполняемый файл напрямую, например:

$ ./src/unit_tests_dbms --gtest_filter=LocalAddress*

Тесты производительности

Тесты производительности позволяют измерять и сравнивать производительность некоторой изолированной части ClickHouse на синтетических запросах. Тесты производительности расположены в tests/performance/. Каждый тест представлен файлом .xml с описанием тестового случая. Тесты запускаются с помощью инструмента docker/test/performance-comparison. Смотрите файл readme для вызова.

Каждый тест выполняет один или несколько запросов (возможно, с комбинациями параметров) в цикле.

Если вы хотите улучшить производительность ClickHouse в каком-то сценарии, и улучшения могут быть замечены на простых запросах, настоятельно рекомендуется написать тест производительности. Также рекомендуется писать тесты производительности, когда вы добавляете или модифицируете SQL-функции, которые относительно изолированы и не слишком неясны. Всегда имеет смысл использовать perf top или другие инструменты perf во время ваших тестов.

Инструменты и скрипты тестирования

Некоторые программы в директории tests не являются подготовленными тестами, а являются инструментами тестирования. Например, для Lexer есть инструмент src/Parsers/tests/lexer, который просто выполняет токенизацию stdin и записывает окрашенный результат в stdout. Вы можете использовать такие инструменты в качестве примеров кода и для исследований и ручного тестирования.

Разные тесты

Существуют тесты для машинно обученных моделей в tests/external_models. Эти тесты не обновляются и должны быть перенесены в интеграционные тесты.

Есть отдельный тест для вставок кворума. Этот тест запускает кластер ClickHouse на отдельных серверах и эмулирует различные случаи сбоев: сетевой разрыв, потеря пакетов (между узлами ClickHouse, между ClickHouse и ZooKeeper, между сервером ClickHouse и клиентом и т.д.), kill -9, kill -STOP и kill -CONT, как Jepsen. Затем тест проверяет, что все подтвержденные вставки были записаны, а все отклоненные вставки не были.

Тест кворума был написан отдельной командой до того, как ClickHouse был открыт. Эта команда больше не работает с ClickHouse. Тест был случайно написан на Java. По этим причинам тест кворума должен быть переписан и перемещен в интеграционные тесты.

Ручное тестирование

Когда вы разрабатываете новую функцию, разумно также протестировать ее вручную. Вы можете сделать это с помощью следующих шагов:

Соберите ClickHouse. Запустите ClickHouse из терминала: перейдите в директорию programs/clickhouse-server и запустите его с ./clickhouse-server. По умолчанию он будет использовать конфигурацию (config.xml, users.xml и файлы в директориях config.d и users.d) из текущей директории. Чтобы подключиться к серверу ClickHouse, выполните programs/clickhouse-client/clickhouse-client.

Обратите внимание, что все инструменты clickhouse (сервер, клиент и т.д.) просто символические ссылки на один бинарный файл под названием clickhouse. Вы можете найти этот бинарный файл в programs/clickhouse. Все инструменты также можно вызывать как clickhouse tool вместо clickhouse-tool.

В качестве альтернативы вы можете установить пакет ClickHouse: либо стабильный релиз из репозитория ClickHouse, либо собрать пакет самостоятельно с помощью ./release в корне исходников ClickHouse. Затем запустите сервер с sudo clickhouse start (или используйте stop для остановки сервера). Ищите логи в /etc/clickhouse-server/clickhouse-server.log.

Когда ClickHouse уже установлен в вашей системе, вы можете собрать новый бинарный файл clickhouse и заменить существующий бинарный файл:

$ sudo clickhouse stop
$ sudo cp ./clickhouse /usr/bin/
$ sudo clickhouse start

Также вы можете остановить системный clickhouse-server и запустить свой собственный с теми же настройками, но с логированием в терминал:

$ sudo clickhouse stop
$ sudo -u clickhouse /usr/bin/clickhouse server --config-file /etc/clickhouse-server/config.xml

Пример с gdb:

$ sudo -u clickhouse gdb --args /usr/bin/clickhouse server --config-file /etc/clickhouse-server/config.xml

Если системный сервер clickhouse-server уже запущен и вы не хотите его останавливать, вы можете изменить номера портов в вашем config.xml (или переопределить их в файле в директории config.d), предоставить соответствующий путь к данным и запустить его.

Бинарный файл clickhouse имеет почти нулевые зависимости и работает на большом количестве дистрибутивов Linux. Для быстрого тестирования ваших изменений на сервере вы можете просто scp свой свежесобранный бинарный файл clickhouse на свой сервер и затем запустить его, как в примерах выше.

Тесты сборки

Тесты сборки позволяют проверить, что сборка не сломана на различных альтернативных конфигурациях и на некоторых сторонних системах. Эти тесты также автоматизированы.

Примеры:

• кросс-компиляция для Darwin x86_64 (macOS)
• кросс-компиляция для FreeBSD x86_64
• кросс-компиляция для Linux AArch64
• сборка на Ubuntu с библиотеками из системных пакетов (не рекомендуется)
• сборка с разделяемой связкой библиотек (не рекомендуется)

Например, сборка с системными пакетами — плохая практика, потому что мы не можем гарантировать, какая именно версия пакетов будет у системы. Но это действительно необходимо для мейнтейнеров Debian. По этой причине мы, по крайней мере, должны поддерживать этот вариант сборки. Другой пример: использование разделяемой связки является распространенной причиной проблем, но это нужно некоторым энтузиастам.

Хотя мы не можем запускать все тесты на всех вариантах сборок, мы хотим проверить, что различные варианты сборки не сломаны. Для этой цели мы используем тесты сборки.

Также мы тестируем, что нет единиц перевода, которые слишком длинные для компиляции или требуют слишком много ОЗУ.

Мы также тестируем, что нет слишком больших стековых фреймов.

Тестирование на совместимость протоколов

Когда мы расширяем сетевой протокол ClickHouse, мы вручную тестируем, что старый клиент clickhouse работает с новым сервером clickhouse, и новый клиент clickhouse работает со старым сервером clickhouse (просто запустив бинарные файлы из соответствующих пакетов).

Мы также тестируем некоторые случаи автоматически с помощью интеграционных тестов:

• если данные, записанные старой версией ClickHouse, могут быть успешно прочитаны новой версией;
• работают ли распределенные запросы в кластере с различными версиями ClickHouse.

Помощь от компилятора

Основной код ClickHouse (который находится в директории src) собирается с флагами -Wall -Wextra -Werror и с некоторыми дополнительными включенными предупреждениями. Хотя эти параметры не включены для сторонних библиотек.

Clang имеет еще больше полезных предупреждений - вы можете искать их с помощью -Weverything и выбрать что-то для сборки по умолчанию.

Мы всегда используем clang для сборки ClickHouse как для разработки, так и для производства. Вы можете собрать на своем компьютере в режиме отладки (чтобы сохранить заряд батареи вашего ноутбука), но обратите внимание, что компилятор может генерировать больше предупреждений с -O3 за счет лучшего контроля потока и анализа межпроцедурных вызовов. При сборке с помощью clang в режиме отладки используется отладочная версия libc++, которая позволяет поймать больше ошибок во время выполнения.

Санитайзеры

примечание

Если процесс (сервер или клиент ClickHouse) выдается с ошибкой при запуске локально, вам может понадобиться отключить рандомизацию расположения адресного пространства: sudo sysctl kernel.randomize_va_space=0

Санитайзер адресов

Мы запускаем функциональные, интеграционные, стрессовые и модульные тесты под ASan на основе каждого коммита.

Санитайзер потоков

Мы запускаем функциональные, интеграционные, стрессовые и модульные тесты под TSan на основе каждого коммита.

Санитайзер памяти

Мы запускаем функциональные, интеграционные, стрессовые и модульные тесты под MSan на основе каждого коммита.

Санитайзер неопределенного поведения

Мы запускаем функциональные, интеграционные, стрессовые и модульные тесты под UBSan на основе каждого коммита. Код некоторых сторонних библиотек не санируется на наличие UB.

Valgrind (memcheck)

Ранее мы запускали функциональные тесты под Valgrind всю ночь, но больше не делаем этого. Это занимает много часов. В настоящее время существует один известный ложноположительный результат в библиотеке re2, смотрите эту статью.

Фаззинг

Фаззинг ClickHouse реализован как с использованием libFuzzer, так и случайных SQL-запросов. Все тестирования на фаззинг должны выполняться с санитайзерами (Адресным и Неопределенным).

LibFuzzer используется для изолированного тестирования библиотечного кода. Фаззеры реализованы как часть тестового кода и имеют суффикс имени "_fuzzer". Пример фаззера можно найти в src/Parsers/fuzzers/lexer_fuzzer.cpp. Конфигурации, специфичные для LibFuzzer, словари и корпуса хранятся в tests/fuzz. Мы призываем вас писать тесты на фаззинг для каждой функции, которая обрабатывает ввод от пользователя.

Фаззеры по умолчанию не собираются. Чтобы собрать фаззеры, следует установить как флаги -DENABLE_FUZZING=1, так и -DENABLE_TESTS=1. Мы рекомендуем отключить Jemalloc при сборке фаззеров. Конфигурацию, использованную для интеграции фаззинга ClickHouse в Google OSS-Fuzz, можно найти в docker/fuzz.

Мы также используем простой тест на фаззинг, чтобы генерировать случайные SQL-запросы и проверять, что сервер не «падает» при их выполнении. Вы можете найти его в 00746_sql_fuzzy.pl. Этот тест следует запускать непрерывно (в течение ночи и дольше).

Мы также используем сложный фаззер запросов на основе AST, который способен находить огромное количество крайних случаев. Он выполняет случайные перестановки и подстановки в AST запросов. Он запоминает узлы AST из предыдущих тестов, чтобы использовать их для фаззинга последующих тестов, обрабатывая их в случайном порядке. Вы можете узнать больше об этом фаззере в этой статье блога.

Стресс-тест

Стресс-тесты — это еще один случай фаззинга. Он запускает все функциональные тесты параллельно в случайном порядке на одном сервере. Результаты тестов не проверяются.

Проверяется, что:

• сервер не «падает», не срабатывают отладочные или санитайзерные ловушки;
• нет взаимоблокировок;
• структура базы данных согласованна;
• сервер может успешно остановиться после теста и запуститься снова без исключений.

Существует пять вариантов (Debug, ASan, TSan, MSan, UBSan).

Фаззер потоков

Фаззер потоков (не путать с санитайзером потоков) — это еще один вид фаззинга, который позволяет рандомизировать порядок выполнения потоков. Он помогает находить еще более специальные случаи.

Аудит безопасности

Наша команда безопасности провела некоторый общий обзор возможностей ClickHouse с точки зрения безопасности.

Статические анализаторы

Мы запускаем clang-tidy на основе каждого коммита. Проверки clang-static-analyzer также включены. clang-tidy также используется для некоторых проверок стиля.

Мы оценили clang-tidy, Coverity, cppcheck, PVS-Studio, tscancode, CodeQL. Вы найдете инструкции по использованию в директории tests/instructions/.

Если вы используете CLion в качестве IDE, вы можете воспользоваться некоторыми проверками clang-tidy из коробки.

Мы также используем shellcheck для статического анализа оболочки скриптов.

Укрепление

В сборке отладки мы используем пользовательский аллокатор, который выполняет ASLR для пользовательских аллокаций.

Мы также вручную защищаем области памяти, которые должны оставаться только для чтения после аллокации.

В сборке отладки мы также включаем настройку библиотеки libc, которая гарантирует, что не будут вызваны «вредные» (устаревшие, небезопасные, не потокобезопасные) функции.

Отладочные утверждения используются широко.

В сборке отладки, если исключение с кодом «логическая ошибка» (предполагает наличие ошибки) выбрасывается, программа преждевременно завершается. Это позволяет использовать исключения в сборке релиза, но сделать это утверждением в сборке отладки.

Отладочная версия jemalloc используется для сборок отладки. Отладочная версия libc++ используется для сборок отладки.

Проверки целостности во время выполнения

Данные, хранящиеся на диске, проверяются с помощью контрольных сумм. Данные в таблицах MergeTree проверяются с помощью контрольных сумм тремя способами одновременно* (сжатые блоки данных, несжатые блоки данных, общая контрольная сумма по блокам). Данные, передаваемые по сети между клиентом и сервером или между серверами, также проверяются контрольными суммами. Репликация гарантирует битово-идентичные данные на репликах.

Это необходимо для защиты от неисправного аппаратного обеспечения (битовая порча на носителях, битовые перевороты в ОЗУ сервера, битовые перевороты в ОЗУ сетевого контроллера, битовые перевороты в ОЗУ сетевого коммутатора, битовые перевороты в ОЗУ клиента, битовые перевороты на проводе). Обратите внимание, что битовые перевороты — обычное явление и вероятно произойдут даже для ECC ОЗУ и при наличии контрольных сумм TCP (если вам посчастливится запустить тысячи серверов, обрабатывающих петабайты данных каждый день). Смотрите видео (на русском).

ClickHouse предоставляет диагностику, которая поможет операционным инженерам найти неисправное аппаратное обеспечение.

* и это не медленно.

Стиль кода

Правила стиля кода описаны здесь.

Чтобы проверить некоторые распространенные нарушения стиля, вы можете использовать скрипт utils/check-style.

Чтобы заставить ваш код соответствовать правильному стилю, вы можете использовать clang-format. Файл .clang-format находится в корне источников. Он в основном соответствует нашему фактическому стилю кода. Но не рекомендуется применять clang-format к существующим файлам, так как это ухудшает форматирование. Вы можете использовать инструмент clang-format-diff, который вы можете найти в репозитории clang.

В качестве альтернативы вы можете попробовать инструмент uncrustify для переформатирования вашего кода. Конфигурация находится в uncrustify.cfg в корне источников. Он менее протестирован, чем clang-format.

CLion имеет собственный форматировщик кода, который нужно настроить для нашего стиля кода.

Мы также используем codespell для поиска опечаток в коде. Это также автоматизировано.

Покрытие тестами

Мы также отслеживаем покрытие тестами, но только для функциональных тестов и только для clickhouse-server. Это выполняется на ежедневной основе.

Тесты для тестов

Существует автоматическая проверка на ненадежные тесты. Она запускает все новые тесты 100 раз (для функциональных тестов) или 10 раз (для интеграционных тестов). Если хотя бы один раз тест дал сбой, он считается ненадежным.

Автоматизация тестов

Мы запускаем тесты с помощью GitHub Actions.

Работы по сборке и тестам выполняются в Sandbox на основе каждого коммита. Результирующие пакеты и результаты тестирования публикуются на GitHub и могут быть загружены по прямым ссылкам. Артефакты хранятся на протяжении нескольких месяцев. Когда вы отправляете запрос на объединение на GitHub, мы помечаем его как «можно протестировать», и наша CI-система соберет пакеты ClickHouse (релизные, отладочные, с адресным санитайзером и т.д.) для вас.