Copilot Code Review теперь может одобрять pull request'ы

2026-09-01 GitHub выпустил изменение, которое переводит Copilot Code Review из роли комментатора в роль инстанции, принимающей решение: Copilot code review can now approve pull requests. Функция доступна в публичной предварительной версии для Copilot Pro, Pro+, Max, Business и Enterprise.

Здесь появились две разные вещи, и именно их смешение приводит команды к неприятным сюрпризам.

Оценка это не одобрение

Каждое ревью Copilot теперь завершает обзорный комментарий оценкой готовности к одобрению: суждением Copilot о том, готов ли pull request к одобрению. Эта часть включена у всех и механически ничего не меняет. Это фраза в комментарии, и требований к слиянию она не затрагивает.

Вторая вещь это настоящее одобряющее ревью, которое отправляет copilot-pull-request-reviewer[bot] и которое засчитывается в правило обязательных одобрений репозитория ровно так же, как одобрение коллеги. Оно выключено по умолчанию, и включить его должен администратор на уровне предприятия, организации или репозитория.

Если в вашем репозитории в ruleset ветки стоит “Require 1 approval” и вы это включаете, вы не добавили ревьюера. Вы сделали человека необязательным.

Ограничьте область glob-масками до включения

Настройка уровня репозитория принимает список glob-масок файлов, по одной на строку, и засчитывает одобрение Copilot только “в pull request’ах, где каждый изменённый файл соответствует одной из масок”. Ключевое слово здесь каждый. Pull request, который затрагивает docs/setup.md и src/Payments/Charge.cs, не получит засчитываемого одобрения, если ваш список масок покрывает только документацию. Это и есть правильная стартовая позиция: начинайте с путей, где ошибочное одобрение обходится дёшево.

Одобрения также сбрасываются при пуше новых коммитов, как и одобрение человека в репозитории, настроенном на сброс устаревших ревью. То есть сценарий отказа это не старая подпись, пережившая force push.

Автоматическое ревью это правило ruleset, и его можно задать скриптом

Переключатель одобрения живёт в настройках, но само наличие ревью от Copilot задаётся правилом ruleset ветки (copilot_code_review), поэтому его можно создать через API, а не кликами:

gh api repos/OWNER/REPO/rulesets --method POST --input - <<'JSON'
{
  "name": "copilot-review-main",
  "target": "branch",
  "enforcement": "active",
  "conditions": { "ref_name": { "include": ["refs/heads/main"], "exclude": [] } },
  "rules": [
    {
      "type": "copilot_code_review",
      "parameters": {
        "review_on_push": true,
        "review_draft_pull_requests": false
      }
    }
  ]
}
JSON

Дополните это аудиторским запросом, потому что готовой панели для этого GitHub не даёт. Одобрения это обычные ревью, поэтому их можно посчитать:

gh api "repos/OWNER/REPO/pulls/123/reviews" \
  --jq '.[] | select(.user.login == "copilot-pull-request-reviewer[bot]") | {state, submitted_at}'

Прогоните это по слитым pull request’ам, и вы получите число, которое действительно важно: сколько слияний прошли порог одобрения без участия человека. Включение review_on_push также многократно увеличивает расход premium requests, что складывается с тем, что уровень усилий ревью по умолчанию меняется с Lite на Balanced 2026-09-28.

Включайте сначала на сгенерированных файлах и документации. Расширяйте, когда получите цифры аудита, но не раньше.