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

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

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

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

git reset
git commit --allow-empty
git push

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

Слияние с мастер​

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

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

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

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

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

Запись в DockerHub​

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

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

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

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

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

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

cpp​

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

codespell, aspell​

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

mypy​

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

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

Вся работа Style Check может быть запущена локально в контейнере Docker с:

python -m ci.praktika run "Style check"

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

python -m ci.praktika run "Style check" --test cpp

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

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

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

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

python -m ci.praktika run "Fast test" [--test some_test_name]

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

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

Создаёт ClickHouse в различных конфигурациях для использования на следующих этапах.

Запуск сборок локально​

Сборку можно запустить локально в среде, похожей на CI, использовав:

python -m ci.praktika run "<BUILD_JOB_NAME>"

Не требуется зависимостей, кроме Python 3 и Docker.

Доступные задачи сборки​

Названия задач сборки точно такие же, как они появляются в отчете CI:

Сборки AMD64:

  • Build (amd_debug) - Отладочная сборка с символами
  • Build (amd_release) - Оптимизированная релизная сборка
  • Build (amd_asan) - Сборка с санитайзером адресов
  • Build (amd_tsan) - Сборка с санитайзером потоков
  • Build (amd_msan) - Сборка с санитайзером памяти
  • Build (amd_ubsan) - Сборка с санитайзером неопределенного поведения
  • Build (amd_binary) - Быстрая релизная сборка без Thin LTO
  • Build (amd_compat) - Сборка совместимости для старых систем
  • Build (amd_musl) - Сборка с musl libc
  • Build (amd_darwin) - Сборка для macOS
  • Build (amd_freebsd) - Сборка для FreeBSD

Сборки ARM64:

  • Build (arm_release) - Оптимизированная релизная сборка ARM64
  • Build (arm_asan) - Сборка ARM64 с санитайзером адресов
  • Build (arm_coverage) - Сборка ARM64 с инструментированием покрытия
  • Build (arm_binary) - Быстрая релизная сборка ARM64 без Thin LTO
  • Build (arm_darwin) - Сборка для macOS ARM64
  • Build (arm_v80compat) - Сборка совместимости ARMv8.0

Другие архитектуры:

  • Build (ppc64le) - PowerPC 64-бит Little Endian
  • Build (riscv64) - RISC-V 64-бит
  • Build (s390x) - IBM System/390 64-бит
  • Build (loongarch64) - LoongArch 64-бит

Если задача завершается успешно, результаты сборки будут доступны в директории <repo_root>/ci/tmp/build.

Примечание: Для сборок, не относящихся к категории "Другие архитектуры" (которые используют кросс-компиляцию), архитектура вашей локальной машины должна соответствовать типу сборки, чтобы создать сборку, как запрашивается BUILD_JOB_NAME.

Пример​

Чтобы запустить локальную отладочную сборку:

python -m ci.praktika run "Build (amd_debug)"

Если приведённый выше подход не подходит, используйте параметры cmake из журнала сборки и следуйте общему процессу сборки.

Функциональные беспоstateные тесты​

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

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

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

Проверка валидации фиксирований​

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

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

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

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

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

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

AST фуззер​

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

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

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