Сведения о предварительных сборках в GitHub Codespaces

Обзор

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

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

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

Когда предварительные сборки доступны для определенной ветви репозитория, определенного файла конфигурации контейнера разработки и для вашего региона, вы увидите метку " Prebuild ready" в списке параметров типа компьютера при создании пространства кода. Если предварительная сборка по-прежнему создается, вы увидите метку " Prebuild in progress. Дополнительные сведения см. в разделе Создание пространства кода для репозитория.

При создании пространства кода из шаблона на странице "Пространства кода" GitHub может автоматически использовать предварительную сборку для ускорения создания. Дополнительные сведения о шаблонах см. в разделе Создание пространства кода на основе шаблона.

Процесс предварительной сборки

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

Когда запускается рабочий процесс предварительной сборки, GitHub создает временную среду codespace, выполняя операции настройки вплоть до любых команд onCreateCommand и updateContentCommand в файле devcontainer.json включительно. Во время создания предварительной сборки команды не postCreateCommand выполняются. Дополнительные сведения об этих командах см. в справочнике по devcontainer.json в документации по VS Code. Затем будет создан и сохранен моментальный снимок созданного контейнера.

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

Когда вы создаете среду codespace из предварительной сборки, GitHub скачивает существующий снимок контейнера из хранилища и развертывает его на новой виртуальной машине, выполняя оставшиеся команды, указанные в конфигурации контейнера разработки. Так как многие операции уже выполнены, например клонирование репозитория, создание codespace из предварительной сборки может быть значительно быстрее, чем создание без предварительной сборки. Это так, когда репозиторий большой и (или) команды onCreateCommand выполняются долго.

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

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

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

Например, давайте представим, что выполняется 5 последовательных отправок в ветвь с предварительной конфигурацией. В этой ситуации:

• Запуск рабочего процесса выполняется для первой принудительной отправки, чтобы обновить предварительную сборку.

• Если 4 оставшиеся отправки не влияют на конфигурацию контейнера разработки, выполнение рабочего процесса для них ставится в очередь в состоянии "ожидание".

  Если какая-либо из оставшихся 4 отправок изменяет конфигурацию контейнера разработки, то служба не пропустит это и немедленно запустит рабочий процесс создания предварительной сборки, соответствующим образом обновив предварительную сборку в случае успеха.

• После завершения первого запуска рабочие процессы для второй, третьей и четвертой отправок будут отменены, а последний поставленный в очередь рабочий процесс (для пятой отправки) будет запущен и обновит предварительную сборку.