Гайд · TNWS AI
Как ограничить Copilot approvals путями файлов
Настройка File paths для Copilot approvals: glob-шаблоны, позитивные и негативные тесты, ожидаемое поведение и откат.
Задача и применимость
Этот гайд решает конкретную задачу: разрешить учёт Copilot approval только для pull request, в котором каждый изменённый файл относится к заранее одобренной области. Он подходит монорепозиториям и смешанным репозиториям, где документация, тестовые фикстуры или низкорисковые конфигурации отделены от платёжного, инфраструктурного либо security-sensitive кода. Итогом должна стать не просто включённая опция, а воспроизводимая настройка с тестовым pull request, наблюдаемым результатом и понятным откатом.
Важно отделять три слоя. Copilot Code Review анализирует изменения и формирует замечания или решение review. Ruleset и branch protection определяют, что блокирует merge. Люди, тесты и владельцы компонентов отвечают за принятие риска. Изменение одного слоя не отменяет остальные. Поэтому ниже предусмотрены позитивный и негативный тесты, а ожидаемый результат описан через видимые элементы интерфейса, без выдуманных процентов точности.
Что подтверждено в официальной документации
Проверено 13 сентября 2026 года. Поле File paths принимает по одному glob-шаблону на строку. Approval засчитывается только если каждый изменённый файл совпадает хотя бы с одним шаблоном. Пустое поле означает все пути. На дату проверки официальная документация указывает максимум 15 glob-шаблонов.
Основные первоисточники: использование Copilot Code Review, настройка Copilot Code Review и MCP для Copilot в репозитории. Для этого материала использованы только названия функций и поведение, прямо описанные GitHub. Тарифы и цены не приводятся: они не нужны для выполнения процедуры и могут меняться.
Перед началом убедитесь, что у вас есть административные права для нужного уровня — репозитория или организации. Сделайте снимок текущей конфигурации: запишите значение переключателей, имя ruleset, его targets и обязательные checks. Такой baseline позволяет отличить эффект новой настройки от уже существующей политики и быстро вернуть рабочее состояние.
Пошаговая настройка
- Составьте матрицу разрешённых областей и явно перечислите каталоги, которые не должны проходить по автоматическому approval.
- Откройте Settings → Copilot → Code review в репозитории.
- В Approvals включите возможность Copilot approval и, если организационная политика разрешает, его учёт в required approvals.
- В поле File paths добавьте по одному glob на строку. Не оставляйте поле пустым, если хотите ограничение.
- Сохраните настройку и создайте позитивный PR, где все файлы соответствуют разрешённым шаблонам.
- Создайте смешанный тестовый PR: один разрешённый файл и один файл вне шаблонов. Approval не должен засчитываться для merge requirements.
- Проверьте случаи с файлами в корне, вложенными каталогами, переименованием и удалением: ориентируйтесь на реальные пути, показанные в Files changed.
- Задокументируйте шаблоны рядом с политикой репозитория и пересматривайте их при изменении структуры каталогов.
После сохранения не переходите сразу к массовому включению. Откройте страницу ruleset или Code review повторно и убедитесь, что значение сохранилось. Затем проверяйте поведение на отдельной ветке и безопасном PR. В описании PR укажите цель теста, ожидаемый эффект и человека, который подтвердит результат. Это превращает разовую настройку в проверяемую процедуру.
Готовый шаблон для копирования
Скопируйте карточку в issue, change request или описание тестового PR и заполните угловые скобки. Она одновременно служит планом работы и журналом проверки.
Разрешённые пути для Copilot approval
Пример значений поля File paths (по одному на строку):
docs/**
examples/**
tests/fixtures/**
*.md
Негативные тесты:
- src/payments/charge.ts
- .github/workflows/deploy.yml
- infrastructure/prod/main.tf
Условие приёмки: PR с хотя бы одним негативным путём не получает засчитываемый Copilot approval.
Дата проверки продукта: 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 по карточке ниже.
Не придумывай текущие значения, права, тарифы или результат проверки.
Раздели ответ на: предпосылки, точный путь в интерфейсе, позитивный тест,
негативный тест, наблюдаемые критерии успеха, риски и откат.
Если в карточке нет факта, пометь его как «нужно проверить».
<вставьте заполненную карточку>
Реалистичный пример входа и результата
Вход. PR меняет docs/api/auth.md и examples/node/login.js — оба пути разрешены. Второй тестовый PR дополнительно меняет src/auth/token.ts — этот путь не включён.
Ожидаемый результат. Первый PR соответствует политике путей. Во втором PR наличие src/auth/token.ts нарушает условие «каждый файл совпадает», поэтому Copilot approval не должен засчитываться в merge requirements.
Результат считается подтверждённым только по интерфейсу GitHub и, где применимо, по timeline, merge box, атрибуциям или session log. Фраза модели, предположение администратора или отсутствие комментариев не являются достаточным доказательством. Сохраните URL тестового PR и краткую запись того, что наблюдалось до и после изменения.
Как провести позитивный и негативный тест
Позитивный тест должен попадать точно в разрешённую область: выбранный репозиторий, целевая ветка, подходящие пути и завершённые обязательные checks. До запуска запишите ожидаемое событие — например, автоматическое назначение Copilot, появление approval, видимый комментарий или MCP tool call.
Негативный тест меняет ровно одно условие. Это может быть исключённый репозиторий, файл вне glob, отсутствующий внешний идентификатор или выключенный переключатель. Если одновременно изменить несколько условий, невозможно понять причину результата. Для обоих тестов используйте безопасные изменения, которые можно закрыть без merge.
После теста сравните наблюдения с карточкой. Если результат неоднозначен, не расширяйте охват. Верните исходную конфигурацию, проверьте права, порядок rulesets, target branches и состояние PR, затем повторите тест с одним контролируемым изменением.
Типичные ошибки
- Оставить File paths пустым и ожидать запрета.
- Проверять совпадение только по одному файлу PR.
- Использовать слишком широкий / без теста.
- Забыть о workflow, инфраструктурных файлах и файлах в корне.
- Превысить подтверждённый лимит шаблонов вместо упрощения политики.
Есть и общая ошибка: путать «Copilot завершил review» с «изменение можно сливать». Автоматический review — дополнительный сигнал. Обязательные тесты, секрет-сканирование, review владельца кода и внутренние процедуры сохраняют силу. Если Copilot предлагает исправление, просмотрите diff, запустите тесты и только потом принимайте изменение.
Чек-лист финальной проверки
- Открыт правильный owner, repository или organization.
- Исходная конфигурация сохранена для отката.
- Названия пунктов интерфейса сверены с документацией на 13.09.2026.
- Настройка сохранена и повторно открыта для проверки.
- Позитивный тест выполнен на безопасном pull request.
- Негативный тест меняет только одно условие.
- Проверены реальные ruleset, target branches, required reviews и checks.
- Автоматический результат сверён с diff и тестами человеком.
- Ссылки на тестовый PR и наблюдения записаны.
- План отката понятен ответственному администратору.
FAQ
Достаточно ли совпадения одного файла?
Нет. Официальное условие требует, чтобы каждый изменённый файл совпал хотя бы с одним glob.
Что означает пустое поле?
Ограничение по путям не применяется: допускаются все пути.
Сколько шаблонов можно добавить?
На 13 сентября 2026 года документация указывает максимум 15. Перепроверьте источник перед будущим изменением.
Можно ли полагаться только на glob?
Нет. Сохраняйте CI, CODEOWNERS и ручное ревью для чувствительных областей.
Итог
Настройка готова к эксплуатации, когда команда может повторить её по карточке, показать подтверждение в GitHub и объяснить, какое условие должно сработать в позитивном и негативном сценариях. Если подтверждения нет, оставьте пилот ограниченным и не меняйте требования merge для остальных репозиториев. Перед следующим массовым изменением снова откройте официальные источники: возможности Copilot и элементы интерфейса изменяются со временем.
Читайте также
Как учитывать Copilot approvals в требованиях merge
Пошаговая настройка учёта Copilot approvals при merge: режимы организации и репозитория, контроль ruleset и безопасная проверка.
Как добавить HTTP MCP-сервер в Copilot CLI
Подключение remote MCP server через copilot mcp add --transport http: URL, headers, проверка tools и безопасная диагностика.
Как добавить второй каталог в Copilot CLI через --add-dir
Безопасное использование --add-dir в GitHub Copilot CLI: доступ к файлам, доверенные skills/agents, относительные пути и проверка.
Комментарии
Пока тихо. Скажите первое слово