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

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

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

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

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

Слияние с Master​

Проверяет, что PR можно слить с master. Если нет, он завершится с сообщением Не удается получить mergecommit. Чтобы исправить эту проверку, разрешите конфликт, как описано в документации GitHub, или объедините ветку master с вашей веткой pull request с помощью git.

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

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

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

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

Публикация в DockerHub​

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

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

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

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

Выполняет некоторые простые проверки стиля кода на основе regex, используя двоичный файл utils/check-style/check-style (обратите внимание, что его можно запустить локально). Если она не проходит, исправьте ошибки стиля, следуя руководству по стилю кода.

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

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

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

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

Файлы страницы состояния​

  • 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-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

Функциональные безразмерные тесты​

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

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

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

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

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

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

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

Стресс-тест​

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

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

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

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

Fuzzer AST​

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

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

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