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

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

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

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

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


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

Ниже приведено описание конкретных рабочих процессов (workflows), которые запускаются в нашем репозитории.

1. При создании Issue: Automated Issue Triage

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

  • Файл workflow: .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: Continuous Integration (CI)

Этот workflow гарантирует, что все изменения соответствуют нашим стандартам качества перед слиянием (merge).

  • Файл workflow: .github/workflows/ci.yml
  • Когда запускается: При каждом пуше в 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 корректно связаны с задачами и имеют согласованные метки.

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

4. Постоянный триаж Issues: Scheduled Issue Triage

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

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

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

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

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

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

Last updated on