Автоматизация и процессы триажа

Этот документ содержит подробный обзор автоматизированных процессов, которые мы используем для управления и сортировки issues и pull requests. Наша цель — обеспечить оперативную обратную связь и гарантировать, что вклады участников рассматриваются и интегрируются эффективно. Понимание этой автоматизации поможет вам как контрибьютору знать, чего ожидать, и как лучше взаимодействовать с нашими ботами в репозитории.

Основной принцип: Issues и Pull Requests

Прежде всего, почти каждый Pull Request (PR) должен быть связан с соответствующим Issue. Issue описывает «что» и «почему» (баг или фича), тогда как PR — это «как» (реализация). Такое разделение помогает нам отслеживать выполнение задач, расставлять приоритеты и сохранять четкий исторический контекст. Вся наша автоматизация построена вокруг этого принципа.

Подробные сценарии автоматизации

Ниже приведено описание конкретных сценариев автоматизации, работающих в нашем репозитории.

1. Когда вы открываете Issue: Automated Issue Triage

Это первый бот, с которым вы взаимодействуете при создании issue. Его задача — провести первоначальный анализ и применить правильные labels.

• Файл workflow: .github/workflows/qwen-automated-issue-triage.yml
• Когда запускается: Сразу после создания или повторного открытия issue.
• Что делает:
  • Использует модель Qwen для анализа заголовка и содержания issue в соответствии с подробными рекомендациями.
  • Применяет один label area/*: Классифицирует issue по функциональной области проекта (например, area/ux, area/models, area/platform).
  • Применяет один label kind/*: Определяет тип issue (например, kind/bug, kind/enhancement, kind/question).
  • Применяет один label priority/*: Назначает приоритет от 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/qwen-scheduled-pr-triage.yml
• Когда запускается: Каждые 15 минут для всех открытых pull request’ов.
• Что делает:
  • Проверяет наличие связанного issue: Бот сканирует описание вашего PR на наличие ключевых слов, связывающих его с issue (например, Fixes #123, Closes #456).
  • Добавляет status/need-issue: Если связанное issue не найдено, бот добавит к вашему PR метку status/need-issue. Это явный сигнал о том, что необходимо создать и привязать issue.
  • Синхронизирует метки: Если issue привязан, бот проверяет, что метки PR точно совпадают с метками issue. Он добавит недостающие метки, удалит ненужные и снимет метку status/need-issue, если она была.
• Что нужно делать вам:
  • Всегда привязывайте ваш PR к issue. Это самый важный шаг. Добавьте строку вида Resolves #<номер-issue> в описание вашего PR.
  • Это обеспечит правильную категоризацию вашего PR и позволит ему гладко пройти процесс ревью.

4. Постоянная_triage_ задач: Scheduled Issue Triage

Это резервный workflow, который гарантирует, что ни одна задача не будет пропущена в процессе_triage_.

• Файл workflow: .github/workflows/qwen-scheduled-issue-triage.yml
• Когда запускается: Каждый час для всех открытых задач.
• Что делает:
  • Активно ищет задачи, у которых вообще нет лейблов или которые всё ещё имеют лейбл status/need-triage.
  • Затем запускает тот же мощный анализ на основе QwenCode, что и первоначальный_triage_-бот, чтобы применить правильные лейблы.
• Что нужно делать вам:
  • Обычно ничего делать не нужно. Этот workflow является страховкой, чтобы каждая задача в конце концов была классифицирована, даже если первоначальный_triage_ завершился неудачей.

5. Автоматизация релизов

Этот workflow отвечает за процесс сборки и публикации новых версий Qwen Code.

• Файл workflow: .github/workflows/release.yml
• Когда запускается: По расписанию раз в сутки для “nightly” релизов, а также вручную для официальных патчей и минорных релизов.
• Что делает:
  • Автоматически собирает проект, увеличивает номер версии и публикует пакеты в npm.
  • Создаёт соответствующий релиз на GitHub с автоматически сгенерированными release notes.
• Что делать вам:
  • Как контрибьютор, вам не нужно ничего делать. Вы можете быть уверены, что как только ваш PR будет смержен в ветку main, ваши изменения попадут в следующий nightly релиз.

Мы надеемся, что этот подробный обзор окажется полезным. Если у вас есть вопросы по автоматизации или процессам — не стесняйтесь задавать их!