Процессы автоматизации и триажа

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

Руководящий принцип: Issues и Pull Requests

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

Детальные рабочие процессы автоматизации

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

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

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

• Файл рабочего процесса: .github/workflows/qwen-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, предоставьте запрошенные сведения в комментарии.
  • Координаторы могут написать @qwen-code /triage, чтобы запустить триаж повторно.

2. Когда вы открываете Pull Request: Непрерывная интеграция (CI)

Этот рабочий процесс гарантирует, что все изменения соответствуют нашим стандартам качества, прежде чем они могут быть объединены.

• Файл рабочего процесса: .github/workflows/ci.yml
• Когда запускается: При каждом push в pull request.
• Что делает:
  • Линтинг: Проверяет, что ваш код соответствует правилам форматирования и стиля проекта.
  • Тестирование: Запускает полный набор автоматических тестов на macOS, Windows и Linux, а также на нескольких версиях Node.js. Это самая трудоемкая часть процесса CI.
  • Публикация комментария о покрытии: После успешного прохождения всех тестов бот публикует комментарий в вашем PR. Этот комментарий содержит сводку того, насколько хорошо ваши изменения покрыты тестами.
• Что вам следует делать:
  • Убедитесь, что все проверки CI проходят. Зеленая галочка ✅ появится рядом с вашим коммитом после успешного выполнения.
  • Если проверка не прошла (красный крестик ❌), нажмите на ссылку «Подробнее» рядом с неудачной проверкой, чтобы просмотреть логи, определить проблему и отправить исправление.

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

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

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

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