Автоматизация и процессы первичной обработки

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

Руководящий принцип: задачи и запросы на слияние

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

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

Ниже приведён перечень конкретных рабочих процессов автоматизации, запускаемых в нашем репозитории.

1. При создании задачи: «Автоматическая классификация задач»

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

• Файл рабочего процесса: .github/workflows/qwen-automated-issue-triage.yml
• Время запуска: Сразу после создания или повторного открытия задачи.
• Что он делает:
  • Использует модель Qwen для анализа заголовка и описания задачи в соответствии с подробным набором правил.
  • Присваивает одну метку area/*: Категоризирует задачу по функциональной области проекта (например, area/ux, area/models, area/platform).
  • Присваивает одну метку kind/*: Определяет тип задачи (например, kind/bug, kind/enhancement, kind/question).
  • Присваивает одну метку priority/*: Назначает приоритет от P0 (критический) до P3 (низкий) на основе описанного влияния.
  • Может присвоить метку status/need-information: Если в задаче отсутствуют критически важные детали (например, логи или шаги воспроизведения), она будет помечена как требующая дополнительной информации.
  • Может присвоить метку status/need-retesting: Если в задаче указана версия CLI, устаревшая более чем на шесть версий, она будет помечена как требующая повторного тестирования на актуальной версии.
• Что нужно сделать вам:
  • Заполните шаблон задачи максимально полно. Чем больше деталей вы предоставите, тем точнее будет классификация.
  • Если добавлена метка status/need-information, укажите запрошенные данные в комментарии.

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

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

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

3. Постоянная сортировка запросов на слияние: «Аудит PR и синхронизация меток»

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

• Файл рабочего процесса: .github/workflows/qwen-scheduled-pr-triage.yml
• Время выполнения: Каждые 15 минут для всех открытых запросов на слияние.
• Что он делает:
  • Проверяет наличие связанной задачи: бот анализирует описание вашего PR в поисках ключевого слова, связывающего его с задачей (например, Fixes #123, Closes #456).
  • Добавляет метку status/need-issue: если связанная задача не найдена, бот добавляет метку status/need-issue к вашему PR. Это чёткий сигнал о необходимости создать и привязать соответствующую задачу.
  • Синхронизирует метки: если задача действительно привязана, бот обеспечивает полное совпадение меток PR с метками задачи. Он добавит недостающие метки, удалит неподходящие и снимет метку status/need-issue, если она была установлена.
• Что нужно сделать вам:
  • Всегда привязывайте свой PR к задаче. Это самый важный шаг. Добавьте строку вроде Resolves #<номер-задачи> в описание PR.
  • Это гарантирует правильную категоризацию вашего PR и позволит ему беспрепятственно пройти процесс проверки.

4. Постоянная сортировка задач: «Запланированная сортировка задач»

Это резервный рабочий процесс, обеспечивающий, чтобы ни одна задача не осталась без внимания на этапе сортировки.

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

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

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

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

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