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

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

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

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

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

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

1. Когда вы открываете Issue: Автоматическая классификация задач

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

• Файл рабочего процесса: .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)

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

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

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

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

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

4. Постоянная сортировка задач: Scheduled Issue Triage

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

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

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

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

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

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