Regénération du conteneur dans un codespace

À propos de la régénération d’un conteneur de développement

Lorsque vous travaillez dans un codespace, votre environnement de développement est un conteneur Docker qui s’exécute sur une machine virtuelle. Si vous modifiez la configuration de votre conteneur de développement à partir d'un codespace et souhaitez appliquer ces modifications au codespace actuel, vous devez régénérer le conteneur.

Par défaut, lorsque vous régénérez un conteneur de développement, GitHub Codespaces accélère le processus de génération en réutilisant les images mises en cache lors des précédentes générations du conteneur. C'est généralement le moyen le plus rapide d'implémenter des changements dans la configuration de votre conteneur de développement, pour les raisons suivantes.

GitHub Codespaces peut réutiliser les images dans votre cache plutôt que de les récupérer dans les registres des conteneurs.
Les parties de la configuration de votre conteneur de développement qui définissent la façon dont le conteneur est généré, par exemple les caractéristiques du conteneur de développement et les instructions Dockerfile, peuvent avoir déjà été implémentées dans les couches d'image de votre cache, ce qui vous évite d'avoir à attendre que ces processus s'exécutent à nouveau. (Cependant, les commandes de votre configuration qui s'exécutent après la génération du conteneur, telles que onCreateCommand, s'exécuteront à nouveau).

Vous souhaiterez parfois effectuer une régénération complète de votre conteneur. Lors d'une régénération complète, GitHub Codespaces nettoie tous les conteneurs, images et volumes Docker du cache, puis régénère votre conteneur avec les nouvelles images extraites. Tous les réglages définis dans votre configuration s'exécuteront à nouveau, générant ainsi de nouvelles couches d'images. Vous pouvez effectuer une régénération complète après de nombreuses itérations de régénération de votre conteneur avec des images mises en cache, dans des situations telles que les suivantes.

Vous voulez vous assurer que l'installation définie dans votre configuration ne dépend pas des images mises en cache et qu'elle s'exécutera comme prévu lorsque quelqu'un utilisateur créera un nouveau codespace basé sur la configuration. Par exemple, une dépendance peut avoir été supprimée de l'image de base depuis sa dernière insertion dans votre codespace.
Vous voulez libérer l'espace disque utilisé par votre cache, par exemple si vous êtes à court d'espace disque ou si vous voulez minimiser les frais de stockage. Votre cache d'image peut utiliser une quantité importante d'espace disque si vous avez modifié votre image de base plusieurs fois, si vous avez apporté un grand nombre de modifications itératives à votre configuration ou si vous exécutez plusieurs conteneurs avec Docker Compose.

Regénération d’un conteneur

Vous pouvez regénérer un conteneur dans un codespace dans le client web ou l’application de bureau VS Code, ou vous pouvez utiliser GitHub CLI.

Regénération du conteneur de développement dans le client web ou l’application de bureau VS Code

Accédez à VS Code Command Palette en appuyant sur Maj+Commande+P (Mac) ou Ctrl+Maj+P (Windows/Linux).
Commencez à taper « Regénérer » et sélectionnez Codespaces : Regénérer le conteneur.
Sélectionnez Regénérer ou Régénérer complètement dans la boîte de dialogue de confirmation qui s’ouvre.
Si les changements apportés à la configuration de votre conteneur de développement entraînent une erreur de conteneur, votre codespace s’exécute en mode de récupération et vous voyez s’afficher un message d’erreur.
- Pour diagnostiquer l’erreur en révisant les journaux de création, cliquez sur Afficher le journal de création.
- Pour corriger les erreurs identifiées dans les journaux, mettez à jour votre fichier devcontainer.json.
- Pour appliquer les modifications, régénérez votre conteneur.

Utilisation de GitHub CLI pour régénérer un conteneur de développement

Si vous avez changé une configuration de conteneur de développement en dehors de VS Code (par exemple, sur GitHub ou dans un IDE JetBrains), vous pouvez utiliser l’GitHub CLI pour regénérer le conteneur de développement d’un codespace existant.

Dans le terminal, entrez la commande suivante.
```
gh codespace rebuild
```
Vos codespaces sont répertoriés.
Utilisez les touches de direction de votre clavier pour mettre en surbrillance l’espace de code requis, puis appuyez sur Entrée.

Pour effectuer une regénération complète avecl’GitHub CLI, vous pouvez utiliser la commande gh codespace rebuild --full.

Persistance des données lors d’une regénération

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.

Si vous souhaitez conserver des fichiers en dehors du répertoire /workspaces lors d’une regénération, vous pouvez créer, à l’emplacement souhaité du conteneur, un lien symbolique (symlink) vers le répertoire persistant. Par exemple, dans votre répertoire /workspaces/.devcontainer, vous pouvez créer un répertoire config qui sera conservé lors d’une reconstruction. Vous pouvez ensuite créer un lien symbolique vers le répertoire config et son contenu sous forme de postCreateCommand dans votre fichier devcontainer.json.

{
    "image": "mcr.microsoft.com/devcontainers/base:alpine",
    "postCreateCommand": "chmod +x .devcontainer/postCreate.sh && .devcontainer/postCreate.sh"
}

Dans l’exemple de fichier postCreate.sh ci-dessous, le contenu du répertoire config est lié symboliquement au répertoire de base.

#!/bin/bash
ln -sf $PWD/.devcontainer/config $HOME/config && set +x

Pour aller plus loin

« Présentation des conteneurs de développement »