Гайд · TNWS AI
Как ограничить репозитории в ruleset Copilot Code Review
Настройка Include by pattern и Exclude by pattern для организационного ruleset Copilot Code Review с тестовой матрицей.
Задача и применимость
Этот гайд решает конкретную задачу: точно определить, на какие репозитории организации распространяется автоматический Copilot Code Review, используя шаблоны включения и исключения. Он подходит организациям с десятками репозиториев, архивами, шаблонными проектами и критическими системами, где правило нельзя безопасно включить везде. Итогом должна стать не просто включённая опция, а воспроизводимая настройка с тестовым pull request, наблюдаемым результатом и понятным откатом.
Важно отделять три слоя. Copilot Code Review анализирует изменения и формирует замечания или решение review. Ruleset и branch protection определяют, что блокирует merge. Люди, тесты и владельцы компонентов отвечают за принятие риска. Изменение одного слоя не отменяет остальные. Поэтому ниже предусмотрены позитивный и негативный тесты, а ожидаемый результат описан через видимые элементы интерфейса, без выдуманных процентов точности.
Что подтверждено в официальной документации
Проверено 13 сентября 2026 года. В организационном branch ruleset секция Target repositories → Add target предлагает Include by pattern и Exclude by pattern. После ввода шаблона используются кнопки Add inclusion pattern или Add exclusion pattern. Исключения применяются после включений, а критериев может быть несколько.
Основные первоисточники: использование Copilot Code Review, настройка Copilot Code Review и MCP для Copilot в репозитории. Для этого материала использованы только названия функций и поведение, прямо описанные GitHub. Тарифы и цены не приводятся: они не нужны для выполнения процедуры и могут меняться.
Перед началом убедитесь, что у вас есть административные права для нужного уровня — репозитория или организации. Сделайте снимок текущей конфигурации: запишите значение переключателей, имя ruleset, его targets и обязательные checks. Такой baseline позволяет отличить эффект новой настройки от уже существующей политики и быстро вернуть рабочее состояние.
Пошаговая настройка
- Подготовьте полный список репозиториев и отметьте пилотные, критические, архивные и шаблонные. Не проектируйте patterns по нескольким примерам.
- Откройте Organization Settings → Repository → Rulesets и создайте либо откройте branch ruleset для Copilot review.
- В Target repositories нажмите Add target → Include by pattern.
- Введите шаблон пилотной группы и нажмите Add inclusion pattern. При необходимости добавьте несколько независимых критериев.
- Снова нажмите Add target → Exclude by pattern, задайте критические или legacy-исключения и нажмите Add exclusion pattern.
- Помните порядок: исключения применяются после включений. Репозиторий, совпавший с обоими шаблонами, должен быть исключён.
- Настройте Target branches и правило Automatically request Copilot code review, затем активируйте ruleset.
- Проведите матричный тест минимум на включённом, исключённом, совпавшем с обоими и не совпавшем ни с одним репозитории.
После сохранения не переходите сразу к массовому включению. Откройте страницу ruleset или Code review повторно и убедитесь, что значение сохранилось. Затем проверяйте поведение на отдельной ветке и безопасном PR. В описании PR укажите цель теста, ожидаемый эффект и человека, который подтвердит результат. Это превращает разовую настройку в проверяемую процедуру.
Готовый шаблон для копирования
Скопируйте карточку в issue, change request или описание тестового PR и заполните угловые скобки. Она одновременно служит планом работы и журналом проверки.
Матрица Target repositories
Include by pattern: service-*
Exclude by pattern: service-legacy-*
Ожидания:
service-api → включён
service-legacy-payments → исключён (exclusion после inclusion)
web-store → не включён
service-template → <явно решить и при необходимости исключить>
Target branches: <ветка/шаблон>
Rule: Automatically request Copilot code review
Владелец patterns: <team>
Дата проверки продукта: 13.09.2026
Ссылка на официальную документацию: https://docs.github.com/en/copilot/how-tos/copilot-on-github/set-up-copilot/configure-code-review
Если команда использует внутреннего ассистента для подготовки change request, можно дать ему следующий промпт. Он не просит модель менять настройки и поэтому оставляет действие администратору:
Подготовь план изменения GitHub Copilot Code Review по карточке ниже.
Не придумывай текущие значения, права, тарифы или результат проверки.
Раздели ответ на: предпосылки, точный путь в интерфейсе, позитивный тест,
негативный тест, наблюдаемые критерии успеха, риски и откат.
Если в карточке нет факта, пометь его как «нужно проверить».
<вставьте заполненную карточку>
Реалистичный пример входа и результата
Вход. Include: payments-; Exclude: payments-legacy-. Репозитории: payments-api, payments-legacy-core, storefront и payments-template.
Ожидаемый результат. payments-api попадает под ruleset; payments-legacy-core исключается, хотя совпадает с include; storefront не входит. Для payments-template команда фиксирует явное решение и добавляет исключение, если автоматический review там не нужен.
Результат считается подтверждённым только по интерфейсу GitHub и, где применимо, по timeline, merge box, атрибуциям или session log. Фраза модели, предположение администратора или отсутствие комментариев не являются достаточным доказательством. Сохраните URL тестового PR и краткую запись того, что наблюдалось до и после изменения.
Как провести позитивный и негативный тест
Позитивный тест должен попадать точно в разрешённую область: выбранный репозиторий, целевая ветка, подходящие пути и завершённые обязательные checks. До запуска запишите ожидаемое событие — например, автоматическое назначение Copilot, появление approval, видимый комментарий или MCP tool call.
Негативный тест меняет ровно одно условие. Это может быть исключённый репозиторий, файл вне glob, отсутствующий внешний идентификатор или выключенный переключатель. Если одновременно изменить несколько условий, невозможно понять причину результата. Для обоих тестов используйте безопасные изменения, которые можно закрыть без merge.
После теста сравните наблюдения с карточкой. Если результат неоднозначен, не расширяйте охват. Верните исходную конфигурацию, проверьте права, порядок rulesets, target branches и состояние PR, затем повторите тест с одним контролируемым изменением.
Типичные ошибки
- Не учитывать, что exclusion применяется после inclusion.
- Создать слишком широкий include без инвентаризации.
- Забыть шаблонные и архивные репозитории.
- Тестировать один совпавший репозиторий.
- Не задать Target branches и ожидать применения правила.
Есть и общая ошибка: путать «Copilot завершил review» с «изменение можно сливать». Автоматический review — дополнительный сигнал. Обязательные тесты, секрет-сканирование, review владельца кода и внутренние процедуры сохраняют силу. Если Copilot предлагает исправление, просмотрите diff, запустите тесты и только потом принимайте изменение.
Чек-лист финальной проверки
- Открыт правильный owner, repository или organization.
- Исходная конфигурация сохранена для отката.
- Названия пунктов интерфейса сверены с документацией на 13.09.2026.
- Настройка сохранена и повторно открыта для проверки.
- Позитивный тест выполнен на безопасном pull request.
- Негативный тест меняет только одно условие.
- Проверены реальные ruleset, target branches, required reviews и checks.
- Автоматический результат сверён с diff и тестами человеком.
- Ссылки на тестовый PR и наблюдения записаны.
- План отката понятен ответственному администратору.
FAQ
Что происходит при совпадении include и exclude?
Исключение применяется после включения, поэтому репозиторий исключается.
Можно ли задать несколько criteria?
Да. Официальная инструкция допускает несколько критериев targeting.
Как проверить pattern безопасно?
Используйте тестовую матрицу из четырёх классов и небольшие PR без риска.
Достаточно ли Target repositories?
Нет. Для branch ruleset также задаются Target branches и само правило автоматического review.
Итог
Настройка готова к эксплуатации, когда команда может повторить её по карточке, показать подтверждение в GitHub и объяснить, какое условие должно сработать в позитивном и негативном сценариях. Если подтверждения нет, оставьте пилот ограниченным и не меняйте требования merge для остальных репозиториев. Перед следующим массовым изменением снова откройте официальные источники: возможности Copilot и элементы интерфейса изменяются со временем.
Читайте также
Как включить Copilot Code Review для репозиториев организации
Организационный branch ruleset для автоматического Copilot Code Review: охват репозиториев, ветвей, включение и проверка.
Как задать Review effort level для организации GitHub
Настройка Lite или Balanced для Copilot Code Review в организации: критерии выбора, пилот и проверка результата.
Как ограничить Copilot approvals путями файлов
Настройка File paths для Copilot approvals: glob-шаблоны, позитивные и негативные тесты, ожидаемое поведение и откат.
Комментарии
Пока тихо. Скажите первое слово