Проверка кода и CI

После создания Pull Request (PR) автору необходимо пройти рецензирование кода и проверки CI, а также внести все необходимые исправления, прежде чем PR можно будет слить. Это руководство описывает весь процесс от создания PR до слияния. О том, как создать PR, читайте в руководстве по Pull Request.

Обзор процесса:

1. Если у вас нет прав Committer, попросите участника с такими правами изучить изменения и одобрить рабочий процесс CI.
2. Проверьте собственные изменения и при желании запустите локальную проверку с помощью ИИ, используя навык doris-repo-review.
3. После одобрения рабочего процесса CI запустите проверки TeamCity комментарием в PR.
4. Устраните проблемы, выявленные CI и рецензентами, и убедитесь, что все обязательные проверки текущего коммита пройдены.
5. После того как Reviewer и соответствующие Code Owners одобрят код, попросите участника с правами Committer выполнить слияние PR.

1. Попросите участника с правами Committer одобрить рабочий процесс CI

Когда PR создаёт участник без прав Committer, рабочий процесс CI может ожидать одобрения участника сообщества с необходимыми правами. Попросите участника с правами Committer изучить изменения и одобрить рабочий процесс. Одобрение рабочего процесса лишь разрешает CI выполнять код из PR. Оно не означает, что участник с правами Committer одобрил код или согласился выполнить слияние.

Присоединитесь к сообществу Apache Doris в Slack и опубликуйте следующую информацию в канале #dev, чтобы сообщество могло подобрать подходящего Reviewer:

PR: <PR URL>
Module: <affected module>
Change: <one-sentence purpose>
Local validation: <tests already run>
Help needed: Approve CI workflow / Review

Если вы не знаете, к кому обратиться, посмотрите недавно слитые PR для этого модуля или историю коммитов затронутых файлов. Затем в канале #dev можно пригласить участника с правами Committer, знакомого с этим модулем.

2. Проверьте изменения локально

Пока вы ожидаете одобрения рабочего процесса или завершения удалённых проверок CI, самостоятельно проверьте PR:

• Убедитесь, что изменённые файлы соответствуют описанию PR и не содержат посторонних правок.
• Проверьте обычные сценарии выполнения, обработку ошибок, граничные условия и влияние на совместимость.
• Убедитесь, что новое поведение покрыто тестами, а существующие тесты не удалены и не ослаблены без причины.
• При необходимости обновите справочники по конфигурации, пользовательскую документацию, сообщения об ошибках и примечания по обновлению.
• Убедитесь, что в журналах нет паролей, токенов, ключей и других секретов.

Запустите локальную проверку с помощью ИИ, используя doris-repo-review

Apache Doris предоставляет навык doris-repo-review. Он проверяет PR в локальной копии исходного кода Doris тем же методом, что и онлайн-конвейер Code Review. Навык не компилирует код и не запускает тесты, поэтому не заменяет CI.

Установите навыки Apache Doris:

npx skills add apache/doris-skills

В локальной среде должны быть установлены git, CLI gh с настроенной аутентификацией, jq и python3. Локальная копия Doris должна содержать полную историю Git. Находясь в локальной копии исходного кода apache/doris, выполните следующую команду в агенте, поддерживающем навыки:

/doris-repo-review https://github.com/apache/doris/pull/<PR number>

После команды можно указать, на чём сосредоточиться при проверке:

/doris-repo-review https://github.com/apache/doris/pull/<PR number> focus on compatibility and error handling

Навык приводит текущий рабочий каталог к точному коммиту PR и записывает документы с результатами проверки на английском и китайском языках в review-docs/. Перед запуском самостоятельно закоммитьте локальные изменения в отслеживаемых файлах или сохраните их в stash. Навык не сохраняет изменения в stash и не удаляет их за вас, а также может оставить рабочий каталог в состоянии detached HEAD.

Навык автоматически публикует машиночитаемый комментарий PASS от имени локально аутентифицированной учётной записи gh, если выполняются все следующие условия:

• Вердикт проверки — APPROVE, замечаний уровня Blocker или Major нет.
• Проверка достигла согласованного результата, а документы с её результатами прошли валидацию.
• Выбранная модель и уровень рассуждений соответствуют требованиям навыка.
• Текущий коммит PR не изменился за время проверки.

Навык не публикует комментарий PASS, если вынесен вердикт REQUEST_CHANGES, проверка не достигла согласованного результата, среда выполнения не соответствует требованиям или текущий коммит PR изменился. Этот комментарий подтверждает локальную проверку конкретного коммита с помощью ИИ. Он не означает одобрения участником Apache и не заменяет одобрение кода со стороны Reviewer.

3. Запустите CI в TeamCity

После одобрения рабочего процесса CI опубликуйте в PR следующий комментарий, чтобы запустить конвейер TeamCity:

run buildall

run buildall запускает полный набор применимых проверок с учётом изменённых файлов PR. Используйте эту команду для обычного проверочного запуска. Чтобы запустить или повторить отдельную группу проверок, используйте другую команду, которую в настоящее время поддерживает рабочий процесс запуска TeamCity.

Команда	Назначение
run buildall	Запустить полный набор применимых проверок компиляции и тестов
run compile	Запустить проверки компиляции
run beut	Запустить модульные тесты BE
run feut	Запустить модульные тесты FE
run cloudut	Запустить модульные тесты Cloud
run p0	Запустить регрессионные тесты P0
run p1	Запустить регрессионные тесты P1
run external	Запустить регрессионные тесты External
run cloud_p0	Запустить регрессионные тесты Cloud P0
run cloud_p1	Запустить регрессионные тесты Cloud P1
run vault_p0	Запустить регрессионные тесты Vault P0
run nonConcurrent	Запустить регрессионные тесты, которые нельзя выполнять параллельно
run check_coverage	Запустить проверку покрытия кода
run performance	Запустить тесты производительности

Если PR изменяет скрипты конвейера в regression-test/pipeline/, затрагивающие безопасность учётных данных, команды запуска отдельных тестов блокируются. Проверив безопасность скриптов, участник с правами Committer должен использовать run buildall, чтобы подтвердить изменения и запустить конвейер.

4. Определите, успешно ли пройдены проверки CI

Проверки PR делятся на обязательные и необязательные:

• Обязательные проверки: перед слиянием PR должны быть успешно пройдены все обязательные проверки его текущего коммита.
• Необязательные проверки: их результаты дают дополнительную информацию, но напрямую не блокируют слияние. Если такая проверка завершилась с ошибкой, всё равно выясните, вызвана ли она вашими изменениями, а не игнорируйте её.

Если CI завершился с ошибкой, откройте журналы проверки и определите причину: ошибка в коде, ошибка в тесте, проблема инфраструктуры или нестабильный тест. Исправьте ошибки в коде и тестах и отправьте новый коммит. Если вы подозреваете проблему инфраструктуры или нестабильность теста, добавьте в PR URL журнала неудачного запуска и свои доводы, затем попросите участника с правами Committer или сопровождающего модуля помочь с повторным запуском или расследованием.

Каждая отправка изменений меняет текущий коммит PR. Ориентируйтесь только на проверки последнего коммита. Зелёный статус проверки или AI Review PASS для более раннего коммита не распространяется на текущий коммит.

5. Попросите участника с правами Committer запустить онлайн-проверку с помощью ИИ

Участник с правами Committer или другой участник с необходимыми правами в репозитории может запустить онлайн-проверку с помощью ИИ, опубликовав в PR следующий комментарий:

/review

В команде также можно указать, на чём сосредоточиться:

/review focus on compatibility and error handling

Онлайн-проверка с помощью ИИ использует тот же метод рецензирования, что и навык doris-repo-review, но задание попадает в онлайн-очередь и должно дождаться доступных ресурсов. Посмотрите статус code-review и журналы соответствующего запуска GitHub Actions в разделе проверок PR. Не запускайте повторные проверки только потому, что задание какое-то время остаётся в состоянии Queued или Running.

Успешный статус проверки code-review означает, что онлайн-проверка завершилась и опубликовала рецензию. Он не означает, что проверка не выявила проблем. Прочитайте сводку рецензии и комментарии к строкам кода и разберите замечания.

6. Разберите замечания рецензентов и завершите слияние

Получите одобрение Code Owner

Apache Doris использует .github/CODEOWNERS для назначения Code Owners определённым путям в исходном коде. Когда PR изменяет файлы по одному из этих путей, GitHub запрашивает рецензию у соответствующего человека или команды. Если для модуля требуется рецензирование со стороны Code Owner, перед слиянием PR необходимо получить одобрение соответствующего Code Owner.

Одобрение Code Owner, одобрение рабочего процесса CI и одобрение обычного Reviewer — отдельные требования. Одно не заменяет другое. Проверьте раздел рецензентов PR и требования к слиянию, чтобы узнать, ожидается ли рецензия Code Owner. Если вы не знаете, к кому обратиться, ориентируйтесь на актуальный файл CODEOWNERS и опубликуйте URL PR в канале Slack #dev. Список Code Owners не приводится в этом руководстве, поскольку конфигурация репозитория может меняться.

Разберите замечания рецензентов

После получения замечаний от людей или ИИ:

1. Определите, относится ли каждое замечание к текущим изменениям.
2. Устраните обоснованные замечания в коде, тестах или документации и сообщите в ответе, что изменилось.
3. Если замечание неприменимо, объясните техническую причину и приведите подтверждающие данные.
4. Помечайте обсуждение как решённое только после устранения проблемы.
5. После отправки нового коммита повторно запустите затронутые проверки CI и рецензирование. AI Review PASS, привязанный к более раннему коммиту, не распространяется на новый коммит.
6. Если в PR есть конфликты, выполните rebase на последнюю версию целевой ветки и разрешите их.

Попросите участника с правами Committer выполнить слияние, когда PR будет соответствовать всем следующим условиям:

• Описание PR полное, а объём изменений понятен.
• Все замечания рецензентов разобраны.
• Все обязательные проверки последнего коммита PR успешно пройдены.
• В PR нет неразрешённых конфликтов с целевой веткой.
• Reviewer одобрил код.
• Code Owners затронутых путей одобрили код в соответствии с требованиями.

Участник с правами Committer принимает окончательное решение о слиянии на основании рецензирования, результатов CI и правил слияния проекта.