Establecimiento de variables de entorno persistente
Puedes establecer variables de entorno personalizadas persistentes de varias maneras, en función de los espacios de código, repositorios o usuarios a los que quieras que estén disponibles las variables.
Para todos los métodos de configuración de variables personalizadas que se enumeran a continuación, puedes acceder a la variable personalizada en el codespace mediante la sintaxis como echo $VARNAME
.
Para un único codespace
Puedes establecer el valor de la variable de entorno en el archivo ~/.bashrc
o en un archivo de configuración equivalente si no usas el shell de Bash. Por ejemplo, agrega la instrucción VARNAME=value
.
Después de guardar el cambio en este archivo, el valor se establecerá la próxima vez que abras el codespace, o bien puedes establecerlo inmediatamente mediante un comando como source ~/.bashrc
. La variable permanecerá establecida si se detiene e inicia el codespace. Sin embargo, los cambios en los archivos del directorio principal se restablecerán si vuelves a generar el contenedor, por lo que las variables establecidas en el archivo ~/.bashrc
no se conservarán en una recompilación. Para obtener más información, consulta "Impedir que los archivos temporales se eliminen automáticamente".
Para todos los codespaces de un repositorio
Hay tres maneras de establecer variables de entorno personalizadas persistentes para todos los codespaces que crees para un repositorio:
- Puede editar el archivo de configuración
devcontainer.json
del repositorio. - Puede utilizar un Dockerfile personalizado.
- Puede utilizar secretos de entorno de desarrollo.
Editar el archivo de configuración devcontainer.json
del repositorio
Editar el archivo de configuración devcontainer.json
del repositorio y usar la propiedad remoteEnv
para establecer el valor de la variable de entorno:
{
"remoteEnv": {
"VARNAME": "value"
}
}
Usa este método solo para los valores que estés satisfecho con confirmar en el repositorio como texto no cifrado. Para valores confidenciales, como los tokens de acceso, use secretos de entorno de desarrollo.
La variable de entorno se establecerá dentro del proceso del servidor remoto del editor y estará disponible para los subprocesos de ese proceso de servidor remoto, como terminales y sesiones de depuración. Sin embargo, la variable no estará disponible de forma más amplia dentro del contenedor. Este método es útil si no necesitas establecer la variable de entorno para otros procesos en segundo plano que se ejecutan en el inicio y si usas una imagen predefinida y no tienes o quieres un Dockerfile personalizado.
Esta configuración surtirá efecto al recompilar el contenedor o crear un nuevo codespace después de insertar este cambio en el repositorio. Para obtener más información sobre cómo aplicar cambios de configuración a un codespace, consulta "Introducción a los contenedores dev".
Utilizar un Dockerfile personalizado
Si usas un Dockerfile personalizado, puedes establecer la variable de entorno allí agregando ENV VARNAME=value
.
Este método es útil si ya tienes un Dockerfile y deseas establecer una variable en un nivel de contenedor.
Esta configuración surtirá efecto al recompilar el contenedor o crear un nuevo codespace después de insertar este cambio en el repositorio. Para obtener más información sobre cómo aplicar cambios de configuración a un codespace, consulta "Introducción a los contenedores dev".
Utilizar secretos de entorno de desarrollo
Puede usar secretos de entorno de desarrollo para GitHub Codespaces para establecer variables personalizadas para los codespaces creados para el repositorio. Para obtener más información, vea «Administración de secretos específicos de la cuenta para GitHub Codespaces».
Debes usar este método para los valores de variables de entorno que no deseas confirmar en el repositorio como texto no cifrado.
Esta configuración surtirá efecto la próxima vez que crees un codespace para este repositorio o al reiniciar un codespace existente.
Para todos los codespaces que crees
Si deseas establecer una variable de entorno personalizada para todos los espacios de código que crees, puedes establecerlo mediante un archivo en el repositorio dotfiles
. Por ejemplo, agrega VARNAME=value
el archivo .bash_profile
. Las variables de entorno establecidas en un dotfile son personales para ti y no se establecen para nadie más. Para más información sobre los archivos dotfile, consulta "Personalización de GitHub Codespaces para la cuenta".
Impedir que los archivos temporales se eliminen automáticamente
Al crear un codespace, el repositorio se clona en el directorio /workspaces
del codespace. Es un directorio persistente que se monta en el contenedor. Todo cambio que se realice dentro de este directorio (incluida la edición, la adición o la eliminación de archivos) se conserva al detener e iniciar el codespace, así como al recompilar el contenedor en el codespace.
Fuera del directorio /workspaces
, el codespace contiene una estructura de directorios de Linux que varía en función de la imagen de contenedor dev que se utiliza para compilar el codespace. Puede agregar archivos o realizar cambios en los archivos fuera del directorio /workspaces
. Por ejemplo, puede instalar nuevos programas o puede establecer la configuración del shell en un archivo como ~/.bashrc
. Como usuario no raíz, puede que no tengas acceso de escritura automáticamente a ciertos directorios, pero la mayoría de las imágenes permiten el acceso raíz a estos directorios con el comando sudo
.
Fuera de /workspaces
, a excepción del directorio /tmp
, los directorios de un codespace están vinculados al ciclo de vida del contenedor. Esto significa que los cambios que se realicen se conservan al detener e iniciar el codespace, pero no al recompilar el contenedor. Para obtener información sobre cómo crear enlaces simbólicos para conservar los datos fuera del directorio /workspaces
, consulta "Recompilación del contenedor en un codespace".
El directorio /tmp
es una excepción porque se monta en el contenedor, pero no es persistente. Por lo tanto, el contenido del directorio /tmp
se conserva en una recompilación, pero se borra cada vez que se detiene el codespace. Por ejemplo, el directorio /tmp
se borra cuando una sesión de codespace agota el tiempo de espera después de un período de inactividad. Para obtener más información, vea «Configuración del periodo de tiempo de espera para GitHub Codespaces».
Si tienes archivos temporales que deseas que estén disponibles la próxima vez que inicies el codespace, no los guardes en el directorio /tmp
.