Гайд · TNWS AI

Как создать отдельное окружение copilot-code-review.yml

Copilot

13 сентября 2026 6 мин—

Отдельная среда GitHub Copilot Code Review через .github/workflows/copilot-code-review.yml: зависимости, минимальные permissions, проверка workflow и отличие от setup steps.

Задача и применимость

Цель — отделить setup окружения Copilot Code Review от окружения Copilot cloud agent и детерминированно установить зависимости для проверки. Руководство рассчитано на репозиториев, где review нужны линтеры или генераторы, отличающиеся от инструментов coding agent. Успех здесь означает наблюдаемое состояние: сработавший ruleset, корректный scope веток, прочитанная инструкция, использованное окружение или comments в ожидаемой группе изменений. Текст модели без внешней проверки успехом не считается.

Интерфейс, команды, названия файлов и доступность сверены 13 сентября 2026 года по официальной документации GitHub. Цены и универсальные лимиты не приводятся. Любая доступность зависит от плана, policy и прав пользователя; если пункт отсутствует, не имитируйте его альтернативным write-действием.

Подтверждённая механика

GitHub разрешает .github/workflows/copilot-code-review.yml; если файл присутствует, он используется для code review вместо copilot-setup-steps.yml. Review работает в ephemeral development environment.

Точные имена важны: Review new pushes отвечает за повторные циклы, Review draft pull requests — за статус PR, а Review effort level — за глубину. Аналогично, .github/copilot-instructions.md, path-specific instructions и AGENTS.md имеют разные scopes.

Что подготовить до настройки

Запишите OWNER/REPO, target branch, текущий status настройки и критерий отката. Создайте test branch, где нет секретов и production-изменений. Для инструкции подготовьте одно безопасное нарушение правила, которое потом удалите; для окружения — workflow, проверяемый вручную через Actions.

До любого сохранения сделайте screenshot или текстовую запись исходного значения. Это особенно важно для ruleset: ошибка target может распространить review на большее число PR, а дублирующее правило создаст шум. Проверяйте не только включённый checkbox, но и scope.

Готовый шаблон

name: Copilot Code Review Setup

on:
  workflow_dispatch:

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v7
        with:
          node-version: "20"
          cache: npm
      - run: npm ci

Шаблон — стартовая точка. Замените repository, ветки и инварианты на реальные. Не вставляйте tokens, private URLs и персональные данные. Конфигурационные Markdown/YAML-файлы являются управляющим кодом: их нужно читать в diff и проводить через review.

Пошаговые действия

Создайте .github/workflows/copilot-code-review.yml. Не изменяйте общий setup agent, если цель — только review.
Возьмите проверенный workflow проекта и сократите permissions до необходимого минимума, например contents: read для checkout.
Добавьте checkout, установку runtime и детерминированную установку зависимостей. Не фиксируйте неподтверждённые версии: сверяйте action и runtime на дату внедрения.
Оставьте workflow_dispatch для ручной проверки. Настройте trigger изменения самого файла по процессу репозитория.
Откройте PR с workflow и дождитесь GitHub Actions check. Ошибка setup должна быть видна до использования в review.
После merge в default branch вручную запустите workflow из Actions и проверьте log без secrets.
Запросите Copilot review на test PR, которому нужна установленная зависимость.
Сравните session logs и review result. Убедитесь, что используется отдельный файл, а не copilot-setup-steps.yml.

После каждого шага фиксируйте независимый признак: ruleset Active, target branch совпадает, workflow зелёный, comment привязан к ожидаемому файлу. Если признак отсутствует, остановитесь до следующего write-действия.

Готовый промпт

Проверь PR с использованием project linter и generated types. Если setup не готов, сообщи точный шаг окружения и не выдумывай результат теста.

Промпт должен усиливать конфигурацию, а не заменять её. Укажите scope, инварианты и формат доказательства. Просите сценарий отказа и тест, а не абстрактное «улучшить качество». Для draft или частичного diff явно перечисляйте незавершённые части.

Реалистичный пример входа и результата

Вход: Проект Node.js требует npm ci перед lint; отдельный code-review workflow находится в default branch.

Ожидаемый результат: Окружение устанавливает зависимости, review может опираться на линтер; результат подтверждается Actions и session logs.

Проверяйте результат по GitHub UI, timeline, Actions log, session attribution, Reviewed Changes или локальному diff. Количество комментариев не является метрикой качества. Полезное замечание указывает конкретный код, воспроизводимый риск и проверку.

Контрольный эксперимент

Хорошая настройка проверяется двумя примерами. Положительный должен попасть в scope и запустить нужное поведение. Отрицательный — не должен: другая branch, несовпадающий path, unstaged файл или PR без нового push. Такая пара обнаруживает слишком широкий glob и неверный target.

Не создавайте искусственную уязвимость в production-коде. Используйте изолированный test fixture или безопасный логический дефект, который сразу удаляется. Результат эксперимента зафиксируйте в PR description, затем очистите временный код до merge.

Сохраните короткий протокол эксперимента: дата, commit SHA, выбранный scope, ожидаемое и фактическое поведение. Он помогает отличить случайный успешный запуск от воспроизводимой настройки и упрощает повторную проверку после обновления GitHub. Не включайте в протокол содержимое закрытых комментариев, секреты или данные пользователей.

Как оценить качество review

Разделите комментарии на подтверждённые, спорные и нерелевантные. Для подтверждённого создайте тест до исправления. Для спорного найдите документацию или владельца подсистемы. Нерелевантное замечание отклоните, но проверьте, не виновата ли слишком общая инструкция.

После принятой suggestion перечитайте полный diff: локальная кнопка или web suggestion может внести корректный фрагмент, но не проверить соседний код. Запустите обязательные tests, lint и build из репозитория. Copilot review — дополнительный слой, не замена CI и человеческому approval.

Типовые ошибки

Если dedicated файл присутствует, он заменяет setup steps для code review, а не объединяется автоматически.
Workflow с write permissions расширяет риск без необходимости.
Непроверенный action tag или runtime version быстро устаревает — сверяйте перед merge.

Если настройка не сработала, сначала проверяйте scope, branch, head/base, enforcement status и права. Не переключайте сразу несколько флагов: иначе невозможно понять причину. Меняйте одну переменную и повторяйте контрольный experiment.

Безопасность и поддержка

Rulesets и instructions могут влиять на всю команду, поэтому используйте принцип минимального scope. Workflow получает только нужные permissions. В инструкции нельзя включать секреты или предлагать чтение приватных данных. MCP context и внешние tools требуют отдельной оценки доверия.

Раз в квартал или после крупного обновления повторяйте test PR: UI и поведение меняются. В самом документе команды храните дату проверки и ссылку на официальный источник, а не неподтверждённые скриншоты.

Чек-лист финальной проверки

Названия меню, файлов и опций сверены 13 сентября 2026 года.
OWNER/REPO, target branch и scope указаны явно.
Ruleset имеет ожидаемый Enforcement Status.
Положительный test case запустил нужный review.
Отрицательный test case не попал в scope.
В YAML/Markdown нет секретов и внутренних credentials.
Suggestions проверены полным diff и тестами.
Human approvals и branch protection не ослаблены случайно.
Есть понятный способ отката настройки.

FAQ

Как называется файл?

.github/workflows/copilot-code-review.yml.

Что происходит с copilot-setup-steps.yml?

При наличии dedicated файла code review использует его вместо общего setup.

Где проверять?

В Actions и session logs.

Можно ли добавлять secrets?

Только через штатные защищённые механизмы и минимально; никогда не помещайте значения прямо в YAML.

Официальный первоисточник

GitHub Docs

Источник и изменяемые детали проверены 13 сентября 2026 года. Перед повторением после обновления GitHub или IDE снова откройте ссылку и сравните точные имена пунктов.