Настройка переменных постоянной среды
Постоянные настраиваемые переменные среды можно задать несколькими способами в зависимости от того, какие пространства кода, репозитории или пользователи должны быть доступны.
Для всех методов настройки пользовательских переменных, перечисленных ниже, вы можете получить доступ к пользовательской переменной в codespace с помощью синтаксиса, например echo $VARNAME
.
Для одного codespace
Значение переменной среды можно задать в ~/.bashrc
файле или в эквивалентном файле конфигурации, если вы не используете оболочку Bash. Например, добавьте оператор VARNAME=value
.
После сохранения изменений в этом файле значение будет задано при следующем открытии codespace или его можно задать немедленно с помощью такой команды, как source ~/.bashrc
. Переменная останется заданной, если остановить и запустить codespace. Однако изменения в файлах в домашнем каталоге будут сброшены при перестроении контейнера, поэтому переменные, заданные ~/.bashrc
в файле, не будут сохраняться при перестроении. Дополнительные сведения см. в разделе Предотвращение автоматического удаления временных файлов.
Для всех кодовых пространств для репозитория
Существует три способа задания постоянных настраиваемых переменных среды для всех кодовых пространств, создаваемых для репозитория:
- Вы можете изменить файл конфигурации
devcontainer.json
для репозитория. - Вы можете использовать пользовательский dockerfile
- Вы можете использовать зашифрованные секреты
Изменение файла конфигурации devcontainer.json
для репозитория
Измените devcontainer.json
файл конфигурации для репозитория и используйте remoteEnv
свойство , чтобы задать значение переменной среды:
{
"remoteEnv": {
"VARNAME": "value"
}
}
Используйте этот метод только для значений, которые можно зафиксировать в репозитории в виде открытого текста. Для конфиденциальных значений, таких как маркеры доступа, используйте зашифрованные секреты.
Переменная среды будет задана в процессе удаленного сервера редактора и будет доступна для вложенных процессов этого удаленного серверного процесса, таких как терминалы и сеансы отладки. Однако переменная будет недоступна в более широком смысле в контейнере. Этот метод удобен, если переменная среды не требуется задавать для других фоновых процессов, которые выполняются при запуске, а также если вы используете готовый образ и не используете настраиваемый dockerfile.
Этот параметр вступит в силу при перестроении контейнера или создании пространства кода после отправки этого изменения в репозиторий. Дополнительные сведения о применении изменений конфигурации к codespace см. в разделе Основные сведения о контейнерах разработки.
Использование пользовательского файла Dockerfile
Если вы используете пользовательский Dockerfile, можно задать переменную среды, добавив ENV VARNAME=value
.
Этот метод удобен, если у вас уже есть Dockerfile и вы хотите задать переменную на уровне всего контейнера.
Этот параметр вступит в силу при перестроении контейнера или создании пространства кода после отправки этого изменения в репозиторий. Дополнительные сведения о применении изменений конфигурации к codespace см. в разделе Основные сведения о контейнерах разработки.
Использование зашифрованных секретов
Вы можете использовать зашифрованные секреты для GitHub Codespaces, чтобы задать пользовательские переменные для codespace, созданных для репозитория. Дополнительные сведения см. в разделе Управление зашифрованными секретами для codespace.
Этот метод следует использовать для значений переменных среды, которые не нужно фиксировать в репозитории в виде открытого текста.
Этот параметр вступит в силу при следующем создании codespace для этого репозитория или при перезапуске существующего codespace.
Для всех создаваемых кодовых пространств
Если вы хотите задать персонализированную переменную среды для всех создаваемых codespace, ее можно задать с помощью файла в dotfiles
репозитории. Например, добавьте VARNAME=value
в .bash_profile
файл . Переменные среды, заданные в файле точки, являются личными для вас и не задаются для других пользователей. Дополнительные сведения о файлах точек см. в разделе Персонализация GitHub Codespaces для вашей учетной записи.
Предотвращение автоматического удаления временных файлов
При создании codespace репозиторий клонируется в /workspaces
каталог в codespace. Это постоянный каталог, подключенный к контейнеру. Любые изменения, внесенные в этот каталог, включая редактирование, добавление или удаление файлов, сохраняются при остановке и запуске codespace, а также при перестроении контейнера в codespace.
За пределами /workspaces
каталога codespace содержит структуру каталогов Linux, которая зависит от образа, используемого для сборки codespace. Вы можете добавлять файлы или вносить изменения в файлы за пределами /workspaces
каталога. Например, можно установить новые программы или настроить конфигурацию оболочки в файле, ~/.bashrc
например . Как пользователь, не являющийся корневым, вы можете не иметь автоматический доступ на запись в определенные каталоги, но большинство образов разрешают корневой доступ к этим каталогам с помощью sudo
команды .
Вне /workspaces
, за исключением /tmp
каталога, каталоги в codespace привязаны к жизненному циклу контейнера. Это означает, что все внесенные изменения сохраняются при остановке и запуске codespace, но не сохраняются при перестроении контейнера. Сведения о создании символьных ссылок для сохранения данных за пределами каталога см. в /workspaces
разделе Перестроение контейнера в codespace.
Каталог /tmp
является исключением, так как он подключен к контейнеру, но не является постоянным. Таким образом, содержимое /tmp
каталога сохраняется при перестроении, но очищается при каждой остановке codespace. Например, /tmp
каталог очищается при истечении времени ожидания сеанса codespace после периода бездействия. Дополнительные сведения см. в разделе Настройка периода ожидания для GitHub Codespaces.
Если у вас есть временные файлы, которые вы хотите быть доступными при следующем запуске codespace, не сохраняйте их в каталоге /tmp
.