Définition de variables d’environnement persistantes
Vous pouvez définir des variables d’environnement personnalisées persistantes de plusieurs manières, en fonction des codespaces, des dépôts ou des utilisateurs pour lesquels vous souhaitez que les variables soient disponibles.
Pour toutes les méthodes de définition de variables personnalisées listées ci-dessous, vous pouvez accéder à la variable personnalisée dans votre codespace en utilisant une syntaxe telle que echo $VARNAME.
Pour un seul codespace
Vous pouvez définir la valeur de la variable d’environnement dans le fichier ~/.bashrc ou dans un fichier de configuration équivalent si vous n’utilisez pas l’interpréteur de commandes Bash. Par exemple, ajoutez l’instruction VARNAME=value.
Une fois que vous avez enregistré le changement dans ce fichier, la valeur sera définie lors de la prochaine ouverture du codespace, ou vous pouvez la définir tout de suite en utilisant une commande telle que source ~/.bashrc. La variable reste définie si vous arrêtez et démarrez le codespace. Toutefois, les changements dans les fichiers du répertoire de base sont réinitialisés si vous regénérez le conteneur, donc les variables définies dans le fichier ~/.bashrc ne sont pas conservées après une regénération. Pour plus d’informations, consultez « Empêcher les fichiers temporaires d’être automatiquement supprimés ».
Pour tous les codespaces d’un dépôt
Vous avez trois façons de définir des variables d’environnement personnalisées persistantes pour tous les codespaces que vous créez pour un dépôt :
- Vous pouvez modifier le fichier de configuration
devcontainer.jsondu dépôt. - Vous pouvez utiliser un Dockerfile personnalisé.
- Vous pouvez utiliser les secrets de l’environnement de développement.
Modifier le fichier de configuration devcontainer.json du dépôt
Modifiez le fichier de configuration devcontainer.json du dépôt et utilisez la propriété remoteEnv pour définir la valeur de la variable d’environnement :
{
"remoteEnv": {
"VARNAME": "value"
}
}
Utilisez cette méthode uniquement pour les valeurs que vous voulez commiter dans votre dépôt en texte clair. Pour les valeurs sensibles telles que les jetons d’accès, utilisez des secrets d’environnement de développement.
La variable d’environnement est définie dans le processus de serveur distant de votre éditeur et est disponible pour les sous-processus de ce processus de serveur distant, comme les terminaux et les sessions de débogage. Toutefois, la variable n’est pas disponible plus largement à l’intérieur du conteneur. Cette méthode est utile si vous n’avez pas besoin que la variable d’environnement soit définie pour d’autres processus en arrière-plan qui s’exécutent au démarrage, et si vous utilisez une image prédéfinie et que vous n’avez pas besoin ni ne voulez d’un dockerfile personnalisé.
Ce paramètre prend effet lorsque vous regénérez votre conteneur ou créez un codespace après avoir poussé ce changement dans le dépôt. Pour plus d’informations sur l’application de modifications de configuration à un codespace, consultez « Présentation des conteneurs de développement ».
Utiliser un Dockerfile personnalisé
Si vous utilisez un Dockerfile personnalisé, vous pouvez y définir la variable d’environnement en ajoutant ENV VARNAME=value.
Cette méthode est utile si vous disposez déjà d’un Dockerfile et que vous souhaitez définir une variable à l’échelle du conteneur.
Ce paramètre prend effet lorsque vous regénérez votre conteneur ou créez un codespace après avoir poussé ce changement dans le dépôt. Pour plus d’informations sur l’application de modifications de configuration à un codespace, consultez « Présentation des conteneurs de développement ».
Utiliser les secrets de l’environnement de développement
Vous pouvez utiliser des secrets d’environnement de développement pour GitHub Codespaces afin de définir des variables personnalisées pour les codespaces créés pour le référentiel. Pour plus d’informations, consultez « Gestion des secrets spécifiques à votre compte pour GitHub Codespaces ».
Utilisez cette méthode pour les valeurs de variable d’environnement que vous ne souhaitez pas commiter dans le dépôt en texte clair.
Ce paramètre prend effet la prochaine fois que vous créez un codespace pour ce dépôt ou lorsque vous redémarrez un codespace existant.
Pour tous les codespaces que vous créez
Si vous souhaitez définir une variable d’environnement personnalisée pour tous les codespaces que vous créez, vous pouvez le faire avec un fichier de votre dépôt dotfiles. Par exemple, ajoutez VARNAME=value dans le fichier .bash_profile. Les variables d’environnement que vous définissez dans un dotfile vous sont personnelles et ne sont définies pour personne d’autre. Pour plus d’informations sur les dotfiles, consultez « Personnalisation de GitHub Codespaces pour votre compte ».
Empêcher les fichiers temporaires d’être automatiquement supprimés
Quand vous créez un codespace, votre dépôt est cloné dans le répertoire /workspaces de votre codespace. Il s’agit d’un répertoire persistant monté dans le conteneur. Tous les changements que vous faites à l’intérieur de ce répertoire, notamment la modification, l’ajout ou la suppression de fichiers, sont conservés quand vous arrêtez et démarrez le codespace, et quand vous regénérez le conteneur dans le codespace.
En dehors de l’annuaire /workspaces, votre codespace contient une structure d’annuaire Linux qui varie en fonction de l’image conteneur de développeur utilisée pour générer votre codespace. Vous pouvez ajouter des fichiers ou apporter des modifications aux fichiers en dehors du répertoire /workspaces. Par exemple, vous pouvez installer de nouveaux programmes ou définir votre configuration d’interpréteur de commandes dans un fichier tel que ~/.bashrc. Comme utilisateur non racine, vous n’avez peut-être pas automatiquement l’accès en écriture sur certains répertoires, mais la plupart des images autorisent l’accès à la racine de ces répertoires avec la commande sudo.
En dehors de /workspaces, à l’exception du répertoire /tmp, les répertoires d’un codespace sont liés au cycle de vie du conteneur. Cela signifie que toutes les modifications que vous apportées sont conservées quand vous arrêtez et démarrez votre codespace, mais ne sont pas conservés quand vous regénérez le conteneur. Pour plus d’informations sur la création de liens symboliques pour conserver des données en dehors du répertoire /workspaces, consultez « Regénération du conteneur dans un codespace ».
Le répertoire /tmp est une exception, car il est monté dans le conteneur, mais il n’est pas persistant. Ainsi, le contenu du répertoire /tmp est conservé lors d’une regénération, mais est effacé chaque fois que le codespace s’arrête. Par exemple, le répertoire /tmp est effacé quand une session du codespace expire après une période d’inactivité. Pour plus d’informations, consultez « Définition de votre délai d'expiration pour GitHub Codespaces ».
Si vous avez des fichiers temporaires et que vous voulez qu’ils soient disponibles la prochaine fois que vous démarrez le codespace, ne les enregistrez pas dans le répertoire /tmp.