Настройка предварительных сборок

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

Все ветви, созданные из родительской ветви с поддержкой предварительных сборок, обычно также получают предварительные сборки для той же конфигурации контейнера разработки. Это связано с тем, что предварительные сборки для дочерних ветвей, которые используют ту же конфигурацию контейнера разработки, что и родительская ветвь, в большинстве случаев идентична, поэтому разработчики могут воспользоваться более быстрым временем создания пространства кода в этих ветвях. См . раздел AUTOTITLE.

Обычно при настройке предварительных сборок для ветви они доступны для различных типов компьютеров. Однако если в репозитории больше 32 ГБ, предварительные сборки не будут доступны для двух- и четырехъядерных компьютеров, так как хранилище ограничено 32 ГБ.

Необходимые компоненты

Предварительные сборки создаются с помощью GitHub Actions. В результате GitHub Actions необходимо включить для репозитория, для которого настраивается предварительная сборка. См . раздел AUTOTITLE.

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

Для репозиториев, принадлежащих организации, можно настроить предварительные сборки, если организация находится на плане GitHub Team или GitHub Enterprise. Кроме того, необходимо добавить метод оплаты и задать ограничение расходов для GitHub Codespaces в учетной записи организации или родительском предприятии. См. раздел [AUTOTITLE и Управление ограничением расходов для GitHub Codespaces](/get-started/learning-about-github/githubs-plans).

Настройка предварительных сборок

1. На GitHubперейдите на главную страницу репозитория.

2. Под именем репозитория щелкните Settings. Если вкладка "Параметры" не отображается, выберите раскрывающееся меню и нажмите кнопку "Параметры".

   

3. В разделе "Код и автоматизация" боковой панели щелкните Codespaces.

4. В разделе "Конфигурация предварительной сборки" выберите Настроить предварительную сборку.

   

5. Выберите ветвь, для которой необходимо настроить предварительные сборки.

   

   Note

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

6. При необходимости в раскрывающемся меню файла конфигурации выберите devcontainer.json файл конфигурации, который вы хотите использовать для предварительной сборки. См . раздел AUTOTITLE.

   

7. Выберите способ автоматического активации обновлений предварительной сборки.

   • Каждая отправка (параметр по умолчанию) — с помощью этого параметра предварительные сборки будут обновляться при каждой отправке в указанную ветвь. Это гарантирует, что пространства кода, созданные из предварительной сборки, всегда будут содержать последнюю конфигурацию пространства кода, включая все недавно добавленные или обновленные зависимости.

   • При изменении конфигурации — с помощью этого параметра предварительные сборки будут обновляться при каждом изменении любого из следующих файлов:

     • .devcontainer/devcontainer.json

       Note

       Обновления предварительной сборки не активируются изменениями devcontainer.json файлов в подкаталогах .devcontainer.

     • Файл Dockerfile, на который ссылается build.dockerfile свойство .devcontainer/devcontainer.json файла.

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

   • Запланировано . С помощью этого параметра вы можете обновить предварительно созданные сборки в пользовательском расписании, определяемом вами. Это может снизить потребление GitHub Actions минут, однако при этом можно создать пространства кода, которые не используют последние изменения конфигурации контейнера разработки.

   

8. При необходимости выберите "Уменьшить предварительную сборку", доступную только для определенных регионов , чтобы создавать предварительные сборки только в указанных регионах. Выберите регионы, в которых должны быть доступны предварительные сборки.

   По умолчанию предварительные сборки создаются во всех доступных регионах, что вызывает расходы на хранение на предварительную сборку.

   

   Note

   • Предварительная сборка в каждом регионе взимает отдельные расходы на хранение. Поэтому следует включить предварительные сборки только для регионов, где они точно будут использоваться. См . раздел AUTOTITLE.
   • Разработчики могут задать свой регион по умолчанию для GitHub Codespaces, что позволяет включить предварительные сборки для меньшего числа регионов. См . раздел AUTOTITLE.

9. При необходимости в разделе "Журнал шаблонов" задайте количество сохраненных версий предварительной сборки. Можно ввести любое число от 1 до 5. Число сохраненных версий по умолчанию равно 2, что означает, что сохраняются только последняя предварительная сборка и предыдущая версия.

   

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

   Если задать количество предварительных версий для сохранения до 1, GitHub Codespaces сохранит только последнюю версию предварительной сборки и будет удалять старую версию при каждом обновлении шаблона. Это означает, что вы не получите предварительно созданное пространство кода, если вернетесь к более старой конфигурации контейнера разработки.

   Существует стоимость хранения, связанная с каждой предварительной версией, которая сохраняется. Например, если вы создаете предварительные сборки в 4 регионах и сохраняете 2 версии, плата будет взиматься за хранение до 8 предварительных сборок. См . раздел AUTOTITLE.

10. При необходимости добавьте пользователей или команды, которые будут получать уведомления при сбое запусков рабочего процесса предварительной сборки для этой конфигурации. Начните вводить имя пользователя, имя команды или полное имя, а затем щелкните его, когда оно появится, чтобы добавить в список. Добавленные пользователи и команды будут получать сообщения электронной почты при сбое предварительной сборки. В сообщении будет содержаться ссылка на журналы выполнения рабочего процесса для изучения проблемы.

    

    Note

    Пользователи получат уведомления только о неудачных предварительных сборках, если они включили уведомления о рабочих процессах неудачных действий в личных параметрах. См . раздел AUTOTITLE.

11. При необходимости в нижней части страницы нажмите кнопку "Показать дополнительные параметры".

    

    В разделе "Дополнительные параметры" при выборе "Отключить оптимизацию предварительной сборки" пространства кода будут созданы без предварительной сборки, если последний рабочий процесс предварительной сборки завершился сбоем или запущен в данный момент. См . раздел AUTOTITLE.

12. Нажмите кнопку Создать.

    Если в конфигурации контейнера разработки для репозитория указаны разрешения на доступ к другим репозиториям, отобразится страница авторизации. Дополнительные сведения о том, как это указано в файле, см. в devcontainer.json разделе "Управление доступом к другим репозиториям в кодовом пространстве".

    Щелкните значок , чтобы просмотреть сведения о необходимых разрешениях.

    

    Нажмите кнопку "Авторизовать" и продолжайте **** предоставлять эти разрешения для создания предварительной сборки. Кроме того, можно нажать кнопку " Продолжить" без авторизации , но при этом пространства кода, созданные из результирующих предстроек, могут работать неправильно.

    Note

    Пользователям, создающим пространства кода с помощью этой предварительной сборки, также будет предложено предоставить эти разрешения.

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

Сведения об изменении и удалении конфигураций предварительной сборки см. в разделе Управление предварительными сборками.

Настройка переменных среды

Чтобы разрешить процессу предварительной сборки доступ к переменным среды, необходимым для создания среды разработки, их можно задать как секреты репозитория Codespaces или как секреты организации Codespaces. Созданные таким образом секреты будут доступны любому пользователю, который создаст среду codespace из этого репозитория. См . раздел AUTOTITLE.

Предварительные сборки не могут использовать секреты на уровне пользователя во время создания среды, поскольку такие секреты недоступны, пока не будет создана среда codespace.

Настройка трудоемких задач для включения в предварительную сборку

Команды onCreateCommand и updateContentCommand можно использовать в devcontainer.json для включения длительных процессов в процесс создания предварительной сборки. См. документацию по Visual Studio Code devcontainer.json справочные материалы.

onCreateCommand выполняется только один раз, когда создается предварительная сборка, в то время как updateContentCommand выполняется при создании предварительной сборки и при последующих обновлениях. Добавочные сборки должны быть включены в updateContentCommand, так как они представляют источник проекта и должны быть включены для каждого обновления предварительной сборки.

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

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