Skip to Content
Автоматизированная Обработка

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

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

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

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


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

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

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

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

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

2. Когда вы открываете Pull Request: Continuous Integration (CI)

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

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

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

4. Постоянная_triage_ задач: Scheduled Issue Triage

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

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

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

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

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

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

Last updated on