# Предоставление предварительной сборке доступа к другим репозиториям

Вы можете разрешить предварительной сборке получить доступ к другим GitHub репозиториям, чтобы он был успешно создан.

По умолчанию рабочий процесс для предварительной конфигурации может получить доступ только к своему содержимому GitHub Actions репозитория. Для создания среды разработки в проекте могут использоваться дополнительные ресурсы, расположенные в других местах.

## Разрешение предварительного доступа на чтение к внешним ресурсам

Вы можете настроить доступ на чтение к другим GitHub репозиториям с тем же владельцем репозитория, указав разрешения в файле, используемом `devcontainer.json` конфигурацией предварительной сборки. Дополнительные сведения см. в разделе [Управление доступом к другим репозиториям в кодовом пространстве](/ru/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces).

> \[!NOTE]
>
> * Таким образом вы можете авторизовать разрешения на чтение, и владелец целевого репозитория должен совпадать с владельцем репозитория, для которого создается предварительная сборка. Например, если вы создаете конфигурацию предварительной сборки для него `octo-org/octocatrepository`, вы сможете предоставить разрешения на чтение для других репозиториев, например `octo-org/octodemo`, если это указано в `devcontainer.json` файле, и у вас есть разрешения самостоятельно.
> * Нельзя использовать подстановочные знаки для указания репозиториев. Необходимо определить разрешения для каждого репозитория, для которого требуется предоставить доступ.

Во время создания или изменения конфигурации предварительной сборки для файла `devcontainer.json`, который настраивает доступ на чтение других репозиториев с тем же владельцем, появится запрос на предоставление этих разрешений после нажатия кнопки **Создать** или **Обновить**. Дополнительные сведения см. в разделе [Настройка предварительных сборок](/ru/codespaces/prebuilding-your-codespaces/configuring-prebuilds#configuring-prebuilds).

## Разрешение доступа на запись предварительной сборки к внешним ресурсам

Если для проекта требуется доступ на запись к ресурсам или внешние ресурсы находятся в репозитории с другим владельцем, отличным от репозитория, для которого создается конфигурация предварительной сборки, можно использовать personal access token для предоставления этого доступа.

Вам потребуется создать личную учетную запись, а затем использовать эту учетную запись для создания personal access token (classic) с соответствующими областями.

1. Создайте новую личную учетную запись в GitHub.

   > \[!WARNING]
   > Хотя вы можете создать personal access token (classic) имеющуюся личную учетную запись, настоятельно рекомендуется создать новую учетную запись с доступом только к целевым репозиториям, необходимым для вашего сценария. Это связано с тем, что разрешение `repository` в маркере доступа предоставляет доступ сразу ко всем репозиториям, к которым есть доступ у соответствующей учетной записи. Дополнительные сведения см. в разделе \[AUTOTITLE и [Создание аккаунта на GitHub](/ru/account-and-profile/how-tos/account-management/creating-an-account-on-github)]\(/actions/reference/security/secure-use).

2. Предоставьте новой учетной записи доступ на чтение к необходимым репозиториям. Дополнительные сведения см. в разделе [Управление доступом пользователя к репозиторию организации](/ru/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/managing-an-individuals-access-to-an-organization-repository).

3. Во время входа в новую учетную запись создайте personal access token (classic) область действия `repo` . При необходимости, если предварительной сборке потребуется скачать пакеты из нее GitHubContainer registry, также выберите `read:packages` область. Дополнительные сведения см. в разделе [Управление личными маркерами доступа](/ru/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).

   ![Снимок экрана: параметры конфигурации "Выбор областей" для выбранной области данных personal access token (classic), с выбранными областями репозитория и "read:packages".](/assets/images/help/codespaces/prebuilds-select-scopes.png)

   Если предварительная сборка будет использовать пакет из GitHubContainer registryнего, необходимо либо предоставить новому учетной записи доступ к пакету, либо настроить пакет для наследования разрешений доступа репозитория, который вы предварительно создаете. Дополнительные сведения см. в разделе [Настройка управления доступом и видимости пакета](/ru/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility).

4. Скопируйте строку маркера. Вы назначите этот Codespaces секрет репозитория.

5. Снова войдите в учетную запись с правами администратора для репозитория.

6. В репозитории, для которого требуется создать GitHub Codespaces предварительные сборки, создайте новый Codespaces секрет `CODESPACES_PREBUILD_TOKEN`репозитория, предоставив ему значение созданного и скопированного маркера. Дополнительные сведения см. в разделе [Управление секретами среды разработки для репозитория или организации](/ru/codespaces/managing-codespaces-for-your-organization/managing-development-environment-secrets-for-your-repository-or-organization#adding-secrets-for-a-repository).

Будет personal access token использоваться для всех последующих предстроек, созданных для репозитория. В отличие от других Codespaces секретов репозитория, секрет используется только для предварительной сборки и не будет доступен для использования в пространствах кода, `CODESPACES_PREBUILD_TOKEN` созданных из репозитория.

## Дополнительные материалы

* [Настройка предварительных сборок](/ru/codespaces/prebuilding-your-codespaces/configuring-prebuilds)
* [Устранение неполадок предварительных сборок](/ru/codespaces/troubleshooting/troubleshooting-prebuilds)