Skip to Content
Руководство для разработчиковDevelopmentАвтоматизация задач и запросов на слияние

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

Этот документ содержит подробный обзор автоматизированных процессов, которые мы используем для управления и триажа 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, если она была.
  • Что вам следует делать:
    • Всегда привязывайте свой PR к issue. Это самый важный шаг. Добавьте строку вида Resolves #<номер-issue> в описание PR.
    • Это обеспечит правильную категоризацию вашего PR и его плавное прохождение через процесс ревью.

4. Регулярный триаж для Issues: Плановый триаж Issue

Это резервный рабочий процесс, гарантирующий, что ни один issue не будет пропущен при триаже.

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

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

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

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

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

Last updated on