Процессы автоматизации и триажа
Этот документ содержит подробный обзор автоматизированных процессов, которые мы используем для управления и триажа issues и pull request. Наша цель — обеспечивать оперативную обратную связь и гарантировать, что вклады (contributions) проверяются и интегрируются эффективно. Понимание этой автоматизации поможет вам, как участнику, знать, чего ожидать, и как лучше взаимодействовать с ботами нашего репозитория.
Руководящий принцип: Issues и Pull Requests
Прежде всего, почти каждый Pull Request (PR) должен быть связан с соответствующим Issue. Issue описывает «что» и «почему» (баг или фича), а PR — «как» (реализация). Такое разделение помогает нам отслеживать работу, расставлять приоритеты и сохранять четкий исторический контекст. Наша автоматизация построена вокруг этого принципа.
Детальные рабочие процессы автоматизации
Ниже приведено описание конкретных сценариев автоматизации, которые выполняются в нашем репозитории.
1. Когда вы открываете Issue: Автоматический триаж Issue
Это первый бот, с которым вы столкнетесь при создании issue. Его задача — выполнить первичный анализ и применить правильные метки.
- Файл рабочего процесса:
.github/workflows/qwen-automated-issue-triage.yml - Когда запускается: Сразу после создания или повторного открытия issue.
- Что делает:
- Использует модель Qwen для анализа заголовка и тела issue на основе подробного набора правил.
- Применяет одну метку
area/*: Категоризирует issue по функциональной области проекта (например,area/ux,area/models,area/platform). - Применяет одну метку
kind/*: Определяет тип issue (например,kind/bug,kind/enhancement,kind/question). - Применяет одну метку
priority/*: Назначает приоритет от P0 (критический) до P3 (низкий) на основе описанного воздействия. - Может применить
status/need-information: Если в issue не хватает критических деталей (например, логов или шагов воспроизведения), он помечается для запроса дополнительной информации. - Может применить
status/need-retesting: Если в issue упоминается версия CLI, которая старше шести версий, он помечается для повторного тестирования на текущей версии.
- Что вам следует делать:
- Заполняйте шаблон issue максимально полно. Чем больше деталей вы предоставите, тем точнее будет триаж.
- Если добавлена метка
status/need-information, предоставьте запрошенные сведения в комментарии.
2. Когда вы открываете Pull Request: Непрерывная интеграция (CI)
Этот рабочий процесс гарантирует, что все изменения соответствуют нашим стандартам качества, прежде чем они могут быть объединены.
- Файл рабочего процесса:
.github/workflows/ci.yml - Когда запускается: При каждом push в pull request.
- Что делает:
- Линтинг: Проверяет, что ваш код соответствует правилам форматирования и стиля проекта.
- Тестирование: Запускает полный набор автоматических тестов на macOS, Windows и Linux, а также на нескольких версиях Node.js. Это самая трудоемкая часть процесса CI.
- Публикация комментария о покрытии: После успешного прохождения всех тестов бот публикует комментарий в вашем PR. Этот комментарий содержит сводку того, насколько хорошо ваши изменения покрыты тестами.
- Что вам следует делать:
- Убедитесь, что все проверки CI проходят. Зеленая галочка ✅ появится рядом с вашим коммитом после успешного выполнения.
- Если проверка не прошла (красный крестик ❌), нажмите на ссылку «Подробнее» рядом с неудачной проверкой, чтобы просмотреть логи, определить проблему и отправить исправление.
3. Регулярный триаж для Pull Request: Аудит PR и синхронизация меток
Этот рабочий процесс выполняется периодически, чтобы все открытые PR были правильно связаны с issues и имели согласованные метки.
- Файл рабочего процесса:
.github/workflows/qwen-scheduled-pr-triage.yml - Когда запускается: Каждые 15 минут для всех открытых pull request.
- Что делает:
- Проверяет наличие связанного issue: Бот сканирует описание PR на наличие ключевого слова, которое связывает его с issue (например,
Fixes #123,Closes #456). - Добавляет
status/need-issue: Если связанный issue не найден, бот добавляет меткуstatus/need-issueв ваш PR. Это четкий сигнал о том, что необходимо создать и привязать issue. - Синхронизирует метки: Если issue связано, бот гарантирует, что метки PR точно совпадают с метками issue. Он добавляет недостающие метки и удаляет те, которые не должны быть, а также удаляет метку
status/need-issue, если она была.
- Проверяет наличие связанного issue: Бот сканирует описание PR на наличие ключевого слова, которое связывает его с issue (например,
- Что вам следует делать:
- Всегда привязывайте свой PR к issue. Это самый важный шаг. Добавьте строку вида
Resolves #<номер-issue>в описание PR. - Это обеспечит правильную категоризацию вашего PR и его плавное прохождение через процесс ревью.
- Всегда привязывайте свой PR к issue. Это самый важный шаг. Добавьте строку вида
4. Регулярный триаж для Issues: Плановый триаж Issue
Это резервный рабочий процесс, гарантирующий, что ни один issue не будет пропущен при триаже.
- Файл рабочего процесса:
.github/workflows/qwen-scheduled-issue-triage.yml - Когда запускается: Каждый час для всех открытых issues.
- Что делает:
- Активно ищет issues, у которых либо вообще нет меток, либо всё ещё есть метка
status/need-triage. - Затем запускает тот же мощный анализ на основе QwenCode, что и бот первичного триажа, для применения правильных меток.
- Активно ищет issues, у которых либо вообще нет меток, либо всё ещё есть метка
- Что вам следует делать:
- Обычно вам ничего не нужно делать. Этот рабочий процесс — страховочная сетка, гарантирующая, что каждый issue в конечном итоге будет категоризирован, даже если первичный триаж не сработал.
5. Автоматизация релизов
Этот рабочий процесс занимается упаковкой и публикацией новых версий Qwen Code.
- Файл рабочего процесса:
.github/workflows/release.yml - Когда запускается: По ежедневному расписанию для «nightly»-релизов и вручную для официальных патч- или минорных релизов.
- Что делает:
- Автоматически собирает проект, увеличивает номера версий и публикует пакеты в npm.
- Создает соответствующий релиз на GitHub со сгенерированными примечаниями к релизу.
- Что вам следует делать:
- Как участнику, вам не нужно ничего делать для этого процесса. Можете быть уверены: как только ваш PR будет объединён в ветку
main, ваши изменения будут включены в ближайший nightly-релиз.
- Как участнику, вам не нужно ничего делать для этого процесса. Можете быть уверены: как только ваш PR будет объединён в ветку
Мы надеемся, что этот подробный обзор был полезен. Если у вас есть вопросы по нашей автоматизации или процессам, пожалуйста, не стесняйтесь задавать их!