Перейти к основному содержимому
Перейти к основному содержимому

Непрерывная интеграция (CI)

Когда вы подаете запрос на изменение, некоторые автоматизированные проверки вашего кода выполняются системой непрерывной интеграции (CI) ClickHouse. Это происходит после того, как мейнтейнер репозитория (кто-то из команды ClickHouse) просматривает ваш код и добавляет метку can be tested к вашему запросу на изменение. Результаты проверок отображаются на странице запроса на изменение GitHub, как описано в документации по проверкам GitHub. Если проверка терпит неудачу, вам может понадобиться её исправить. Эта страница дает обзор проверок, с которыми вы можете столкнуться, и что вы можете сделать, чтобы их исправить.

Если кажется, что ошибка проверки не связана с вашими изменениями, это может быть временная ошибка или проблема с инфраструктурой. Отправьте пустой коммит к запросу на изменение, чтобы перезапустить проверки CI:

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

Слияние с Master​

Проверяет, может ли ПР быть слит с master. Если нет, он завершится с сообщением Cannot fetch mergecommit. Чтобы исправить эту проверку, разрешите конфликт, как описано в документации GitHub, или слейте ветку master в вашу ветку запроса на изменение, используя git.

Проверка документации​

Пытается собрать сайт документации ClickHouse. Она может завершиться с ошибкой, если вы изменили что-то в документации. Наиболее вероятная причина - неправильная ссылка в документации. Перейдите к отчету о проверке и ищите сообщения ERROR и WARNING.

Проверка описания​

Проверяет, соответствует ли описание вашего запроса на изменение шаблону PULL_REQUEST_TEMPLATE.md. Вам нужно указать категорию изменения для вашего изменения (например, исправление ошибки) и написать читаемое пользователем сообщение, описывающее изменение для CHANGELOG.md.

Push To DockerHub​

Создает образы Docker, используемые для сборки и тестов, затем загружает их в DockerHub.

Проверка маркера​

Эта проверка означает, что система CI начала обрабатывать запрос на изменение. Когда у него статус 'pending', это означает, что не все проверки еще были начаты. После того как все проверки будут начаты, статус изменяется на 'success'.

Проверка стиля​

Выполняет различные проверки стиля в кодовой базе.

Базовые проверки в задаче проверки стиля:

cpp​

Выполняет простые проверки стиля кода на основе regex с использованием скрипта ci/jobs/scripts/check_style/check_cpp.sh (который также можно запустить локально).
Если он завершается ошибкой, исправьте проблемы со стилем в соответствии с руководством по стилю кода.

codespell, aspell​

Проверяет грамматические ошибки и опечатки.

mypy​

Выполняет статическую проверку типов для Python-кода.

Запуск задания проверки стиля локально​

Целую задачу Проверка стиля можно запустить локально в контейнере Docker с:

Чтобы запустить конкретную проверку (например, проверку cpp):

Эти команды загружают образ Docker clickhouse/style-test и запускают задание в контейнерной среде. Не требуются зависимости, кроме Python 3 и Docker.

Быстрый тест​

Обычно это первая проверка, которая запускается для ПР. Она собирает ClickHouse и выполняет большинство статeless функциональных тестов, пропуская некоторые. Если она завершится неудачно, дальнейшие проверки не начнутся, пока это не будет исправлено. Посмотрите отчет, чтобы узнать, какие тесты не прошли, а затем воспроизведите ошибку локально, как описано здесь.

Запуск быстрого теста локально:​

Эти команды загружают образ Docker clickhouse/fast-test и запускают задание в контейнерной среде. Не требуются зависимости, кроме Python 3 и Docker.

Проверка сборки​

Собирает ClickHouse в различных конфигурациях для использования в дальнейших этапах. Вам нужно исправить те сборки, которые завершаются неудачей. Логи сборки часто содержат достаточно информации, чтобы исправить ошибку, но вам может понадобиться воспроизвести ошибку локально. Опции cmake можно найти в логе сборки, используйте grep для поиска cmake. Используйте эти опции и следуйте общему процессу сборки.

Детали отчета​

  • Компилятор: clang-19, возможно, с именем целевой платформы
  • Тип сборки: 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: бинарный файл GoogleTest с юнит-тестами ClickHouse.
    • performance.tar.zst: Специальный пакет для тестов производительности.

Специальная проверка сборки​

Выполняет статический анализ и проверки стиля кода с использованием clang-tidy. Отчет аналогичен проверке сборки. Исправьте ошибки, найденные в логе сборки.

Запуск clang-tidy локально:​

Существует удобный скрипт packager, который запускает сборку clang-tidy в docker

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

Запускает статeless функциональные тесты для бинарных файлов ClickHouse, собранных в различных конфигурациях - релиз, отладка, с санитайзерами и т.д. Посмотрите отчет, чтобы увидеть, какие тесты не прошли, а затем воспроизведите ошибку локально, как описано здесь. Обратите внимание, что вам нужно использовать правильную конфигурацию сборки для воспроизведения - тест может не пройти под AddressSanitizer, но пройти в Debug. Скачайте бинарный файл со страницы проверок сборки CI или соберите его локально.

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

Запускает stateful функциональные тесты. Обращайтесь с ними так же, как с функциональными статeless тестами. Разница в том, что они требуют таблицы hits и visits из набора данных clickstream для запуска.

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

Запускает интеграционные тесты.

Проверка исправления ошибок​

Проверяет, что либо добавлен новый тест (функциональный или интеграционный), либо некоторые измененные тесты не проходят с бинарным файлом, собранным из ветки master. Эта проверка запускается, когда к запросу на изменение добавлена метка "pr-bugfix".

Нагрузочный тест​

Запускает статeless функциональные тесты одновременно от нескольких клиентов, чтобы обнаружить ошибки, связанные с конкурентностью. Если он завершится неудачно:

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

Проверка совместимости​

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

AST Fuzzer​

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

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

Измеряет изменения в производительности запросов. Это самая долгая проверка, длящаяся чуть менее 6 часов. Отчет о тестах производительности подробно описан здесь.