Skip to main content
Мы публикуем частые обновления нашей документации, и перевод этой страницы, возможно, еще выполняется. Актуальные сведения см. в документации на английском языке.

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

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

Общие сведения

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

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

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

Если для определенной ветви репозитория, файла конфигурации контейнера разработки и вашего региона доступны предварительные сборки, вы увидите метку " Доступна предварительная сборка" в списке типов компьютеров при создании codespace. Если предварительная сборка все еще создается, вы увидите метку " Предварительная сборка выполняется". Дополнительные сведения см. в разделе Создание codespace для репозитория.

Снимок экрана: список доступных типов компьютеров: 2, 4, 8, 16 и 32 ядра с меткой "Готово к предварительной сборке".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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