Расширенная поддержка API позволяет переносить на GitHub App больше сценариев корпоративной и организационной автоматизации, для которых раньше использовали classic PAT. Чтобы настроить разрешения без лишнего доступа, сначала разберите каждую автоматизированную операцию, затем сопоставьте её с нужным разрешением и уровнем Read или Write. Ниже — последовательность планирования по перечню GitHub; она не заменяет инструкцию по установке или проверке приложения.
Предпосылки: когда переносить автоматизацию на GitHub App
GitHub сообщает, что установка GitHub Apps на уровне enterprise стала общедоступной, а новые и расширенные разрешения предназначены прежде всего для управления политиками, безопасностью и административными настройками. Обновление закрывает и два пробела в поддержке на уровне организации. Это расширяет круг сценариев, в которых можно заменить classic PAT, но не означает, что любой существующий скрипт можно перенести без изменений.
Перед настройкой соберите перечень действий автоматизации: например, чтение запросов на обход политик, изменение настроек репозитория или управление списком IP. Для каждого действия отметьте, к какому уровню оно относится — enterprise или организация, — и требуется ли только чтение либо изменение данных. Такой список нужен, чтобы выбирать разрешения по выполняемой задаче, а не включать все административные права сразу.
Официальный перечень новых и расширенных возможностей опубликован в GitHub Changelog. В нём описаны разрешения и связанные API, но не пошаговая настройка приложения, установка, получение токена или проверка запросов. Поэтому приведённая ниже последовательность помогает составить карту разрешений; она не является проверенной инструкцией по выполнению этих операций.
Шаг 1. Разложите сценарии по задачам и требуемому доступу
Составьте отдельную строку для каждой операции и зафиксируйте её цель, уровень (enterprise или организация), нужные данные и результат: чтение или изменение. Не объединяйте чтение и запись только потому, что обе операции относятся к одной системе. В описании GitHub часть разрешений явно обозначена как Read, часть — Write, а часть — Read/write.
- Опишите действие. Запишите, что именно делает автоматизация: читает запросы на обход, меняет правила репозитория, обновляет профиль enterprise или управляет записями списка IP.
- Уточните уровень. Отметьте, относится ли действие к enterprise или к отдельной организации. Некоторые возможности существуют на обоих уровнях, например работа с проверяемыми доменами и IP allowlist.
- Отделите чтение от изменений. Для каждого сценария укажите, достаточно ли получать данные или приложение должно создавать, обновлять, удалять либо включать настройки.
- Сопоставьте действие с разрешением. Используйте названия и уровни доступа из перечня ниже; не выводите нужное разрешение только из названия API или функции.
- Зафиксируйте пробелы. Если точное действие в перечне не названо, не считайте его покрытым автоматически: источник не описывает все методы, условия вызова и особенности установки.
Итогом этого шага должна быть таблица для вашей команды с колонками «операция», «уровень», «Read/Write» и «разрешение GitHub App». Она не доказывает, что конкретный рабочий процесс уже перенесён: это план сопоставления с опубликованной поддержкой.
Шаг 2. Выберите разрешения GitHub App для каждого сценария
Для политик enterprise и организации сопоставьте операции с Enterprise organization and repository policies (Read/write). GitHub указывает чтение полей политик через EnterpriseOwnerInfo и изменение ряда настроек: приватного форка, значений разрешений по умолчанию, видимости, создания и удаления репозиториев, удаления issues, приглашений collaborators, deploy keys, protected branch updates, а также настроек dependency insights и проектов. Это широкий набор изменений: включайте его в план только если автоматизации действительно нужны соответствующие операции.
Если сценарий только читает запросы на обход правил, предусмотрено отдельное Enterprise bypass requests с доступом Read. Для чтения данных enterprise, включая server installations и приглашения организаций, и обновления профиля предназначено Enterprise settings (Read/write). GitHub отдельно отмечает, что Read для Enterprise settings требуется для доступа к Enterprise organization and repository policies.
Для двухфакторной аутентификации выберите Enterprise two-factor authentication (Read/write), если автоматизация должна читать соответствующие поля или менять требования 2FA и запрещённые методы аутентификации. Для проверяемых доменов указаны Enterprise verifiable domains и organization verifiable domains с уровнем Write. Не повышайте их до Read/write по аналогии с другими разрешениями: опубликованный перечень указывает именно Write.
Для IP allowlist на уровне enterprise или организации предусмотрено Enterprise IP allowlist либо organization IP allowlist с Read/write. Перечень охватывает чтение записей и изменения — создание, обновление и удаление — а также переключение enforcement, доверия к GitHub Apps и пользовательского enforcement для Enterprise Managed Users.
Если нужны ограничения доступа enterprise, сопоставьте задачу с Enterprise access restrictions (Write): оно позволяет включать и отключать эти ограничения. Для управления rulesets через enterprise rules REST API и RepositoryRuleset в GraphQL указано Enterprise repository rulesets (Write). Поскольку источник не приводит примеров запросов, он не позволяет по одному этому описанию восстановить формат вызова или последовательность проверки ответа.
Шаг 3. Проверьте существующие разрешения с расширенной поддержкой
Не вся новая поддержка означает появление нового разрешения. У существующего Enterprise people (Read/write) расширено покрытие: оно включает чтение EnterpriseRepositoryInfo, в том числе сведений о репозиториях через EnterpriseOwnerInfo.outsideCollaborators, и добавление себя в организацию с ролью owner или member. У Enterprise billing добавлена возможность с уровнем Write обновлять настройку покупки участников для Marketplace.
Если ваша автоматизация выполняет одну из этих операций, внесите её в карту разрешений отдельно и укажите, что речь идёт о расширенном покрытии существующего разрешения. Не делайте вывод, что вместе с ним автоматически разрешены другие действия с людьми, организацией или биллингом: GitHub перечисляет конкретно названные возможности.
Результат и характерные ограничения при миграции
После сопоставления у вас будет перечень разрешений, которые нужно рассмотреть для каждого сценария, и разделение операций на чтение и изменение. Следующий практический шаг — сверить эту карту с настройками GitHub App и процедурами установки, а затем отдельно спланировать проверку своих рабочих процессов. В доступном описании нет экранов настроек, команд, примеров запросов или журнала выполнения, поэтому нельзя надёжно указать конкретные нажатия, команды проверки токена или ожидаемые ответы API.
Распространённая ошибка при планировании — выбирать Write для операции, которая только читает данные, либо считать, что Read у одного разрешения покрывает соседнюю административную функцию. Исправление: вернитесь к перечню операций, отделите получение данных от изменений и сопоставьте каждую операцию с явно указанным разрешением. Например, для чтения запросов обхода указан Read, а для создания, обновления и удаления записей IP allowlist — Read/write. Если нужная операция не названа, отметьте её как не подтверждённую этим описанием, а не подбирайте разрешение по догадке.
Для GitHub Enterprise Server (GHES) GitHub указывает доступность этих обновлений в версии 3.24. Это не подтверждает наличие поддержки в более ранних версиях или во всех установках GHES: при переносе сначала соотнесите план с целевой версией, а не переносите утверждение о 3.24 на весь продукт.
