Автоматизация и процессы_triage_
Этот документ содержит подробный обзор автоматизированных процессов, которые мы используем для управления и triage issues и pull requests. Наша цель — обеспечить оперативную обратную связь и гарантировать, что вклад участников будет эффективно рассмотрен и интегрирован. Понимание этой автоматизации поможет вам как контрибьютору знать, чего ожидать, и правильно взаимодействовать с нашими ботами в репозитории.
Основной принцип: Issues и Pull Requests
Прежде всего, почти каждый Pull Request (PR) должен быть связан с соответствующим Issue. Issue описывает «что» и «почему» (баг или фича), тогда как PR — это «как» (реализация). Такое разделение помогает нам отслеживать выполнение задач, расставлять приоритеты и сохранять четкий исторический контекст. Наша автоматизация построена вокруг этого принципа.
Подробные схемы автоматизации
Ниже приведено описание конкретных автоматизированных процессов, которые запускаются в нашем репозитории.
1. Когда вы открываете Issue: Automated Issue Triage
Это первый бот, с которым вы взаимодействуете при создании issue. Его задача — провести начальный анализ и применить правильные labels.
- Файл workflow:
.github/workflows/gemini-automated-issue-triage.yml
- Когда запускается: Сразу после создания или повторного открытия issue.
- Что делает:
- Использует модель Gemini для анализа заголовка и содержания issue в соответствии с подробными рекомендациями.
- Применяет один
area/*
label: Классифицирует issue по функциональной области проекта (например,area/ux
,area/models
,area/platform
). - Применяет один
kind/*
label: Определяет тип issue (например,kind/bug
,kind/enhancement
,kind/question
). - Применяет один
priority/*
label: Назначает приоритет от P0 (критический) до P3 (низкий) в зависимости от описанного влияния. - Может применить
status/need-information
: Если в issue отсутствуют важные детали (например, логи или шаги для воспроизведения), он будет помечен как требующий дополнительной информации. - Может применить
status/need-retesting
: Если в issue указана версия CLI, которая устарела более чем на шесть версий, она будет помечена для повторного тестирования на актуальной версии.
- Что делать вам:
- Заполняйте шаблон issue как можно полнее. Чем больше деталей вы предоставите, тем точнее будет триаж.
- Если добавлен label
status/need-information
, пожалуйста, предоставьте запрашиваемые детали в комментарии.
2. Когда вы открываете Pull Request: Continuous Integration (CI)
Этот workflow гарантирует, что все изменения соответствуют нашим стандартам качества перед тем, как их можно будет смержить.
- Файл workflow:
.github/workflows/ci.yml
- Когда запускается: При каждом push в pull request.
- Что делает:
- Lint: Проверяет, что ваш код соответствует правилам форматирования и стилю проекта.
- Test: Запускает полный набор автоматизированных тестов на macOS, Windows и Linux, а также на нескольких версиях Node.js. Это самая длительная часть CI процесса.
- Post Coverage Comment: После успешного прохождения всех тестов бот оставит комментарий к вашему PR. В этом комментарии будет сводка о том, насколько хорошо ваши изменения покрыты тестами.
- Что нужно делать:
- Убедитесь, что все CI проверки прошли успешно. Зеленая галочка ✅ появится рядом с вашим коммитом, если всё выполнено корректно.
- Если какая-то проверка провалилась (красный крестик ❌), нажмите на ссылку “Details” рядом с неудачной проверкой, чтобы посмотреть логи, найти проблему и отправить исправление.
3. Периодическая обработка Pull Request’ов: PR Auditing and Label Sync
Этот workflow запускается периодически, чтобы убедиться, что все открытые PR корректно привязаны к issue и имеют согласованные метки.
- Файл workflow:
.github/workflows/gemini-scheduled-pr-triage.yml
- Когда запускается: Каждые 15 минут для всех открытых pull request’ов.
- Что делает:
- Проверяет наличие связанного issue: Бот сканирует описание вашего PR на наличие ключевых слов, связывающих его с issue (например,
Fixes #123
,Closes #456
). - Добавляет
status/need-issue
: Если связанный issue не найден, бот добавит к вашему PR меткуstatus/need-issue
. Это явный сигнал о том, что нужно создать issue и привязать его к PR. - Синхронизирует метки: Если issue привязан, бот проверяет, что метки PR полностью совпадают с метками issue. Он добавит недостающие метки, удалит ненужные и снимет метку
status/need-issue
, если она была.
- Проверяет наличие связанного issue: Бот сканирует описание вашего PR на наличие ключевых слов, связывающих его с issue (например,
- Что нужно делать вам:
- Всегда привязывайте ваш PR к issue. Это самый важный шаг. Добавьте строку вида
Resolves #<номер-issue>
в описание вашего PR. - Это обеспечит правильную категоризацию вашего PR и позволит ему пройти процесс ревью без задержек.
- Всегда привязывайте ваш PR к issue. Это самый важный шаг. Добавьте строку вида
4. Постоянная_triage_ задач: Scheduled Issue Triage
Это резервный workflow, который гарантирует, что ни одна задача не будет пропущена в процессе_triage_.
- Файл workflow:
.github/workflows/gemini-scheduled-issue-triage.yml
- Когда запускается: Каждый час для всех открытых задач.
- Что делает:
- Активно ищет задачи, у которых вообще нет labels или которые всё ещё имеют label
status/need-triage
. - Затем запускает тот же мощный анализ на основе Gemini, что и начальный_triage_-бот, чтобы применить правильные labels.
- Активно ищет задачи, у которых вообще нет labels или которые всё ещё имеют label
- Что нужно делать вам:
- Обычно ничего делать не нужно. Этот workflow служит страховкой, чтобы каждая задача в конечном итоге была классифицирована, даже если начальный_triage_ завершился неудачей.
5. Автоматизация релизов
Этот workflow отвечает за процесс сборки и публикации новых версий Qwen Code.
- Файл workflow:
.github/workflows/release.yml
- Когда запускается: По расписанию раз в сутки для “nightly” релизов, а также вручную для официальных патчей и минорных релизов.
- Что делает:
- Автоматически собирает проект, обновляет номера версий и публикует пакеты в npm.
- Создаёт соответствующий релиз на GitHub с автоматически сгенерированными release notes.
- Что делать вам:
- Как контрибьютор, вам не нужно ничего делать. Вы можете быть уверены, что как только ваш PR будет смержен в ветку
main
, ваши изменения попадут в следующий nightly релиз.
- Как контрибьютор, вам не нужно ничего делать. Вы можете быть уверены, что как только ваш PR будет смержен в ветку
Мы надеемся, что этот подробный обзор окажется полезным. Если у вас есть вопросы по автоматизации или процессам — не стесняйтесь задавать их!