Présentation approfondie de GitHub Codespaces

GitHub Codespaces est un environnement de développement instantané et basé sur le cloud qui fournit dans un conteneur les langages, les outils et les utilitaires courants dont vous avez besoin pour développer. GitHub Codespaces est également configurable, ce qui vous permet de créer un environnement de développement personnalisé pour votre projet. En configurant un environnement de développement personnalisé pour votre projet, vous pouvez disposer d’une configuration de codespace reproductible pour tous les utilisateurs de votre projet.

Création de votre codespace

Il existe un certain nombre de points d’entrée pour créer un codespace :

À partir d’un modèle GitHub ou d’un dépôt de modèles sur GitHub.com pour démarrer un nouveau projet
À partir d’une branche de votre dépôt pour un travail relatif à de nouvelles fonctionnalités
À partir d’une demande de tirage (pull request) ouverte pour explorer le travail en cours
À partir d’un commit dans l’historique d’un dépôt pour investiguer un bogue à un moment précis

Vous pouvez créer un codespace sur GitHub.com, dans Visual Studio Code ou à l’aide de GitHub CLI.

Votre codespace peut être éphémère si vous souhaitez simplement effectuer un test, ou vous pouvez revenir au même codespace pour travailler sur des fonctionnalité sur le long terme.

Pour plus d’informations, consultez « Création d’un codespace pour un dépôt », « Création d’un codespace à partir d’un modèle » et « Ouverture d’un codespace existant ».

Remarque : Vous pouvez créer plusieurs codespaces par dépôt, voire par branche. Toutefois, il existe des limites au nombre de codespaces que vous pouvez créer, et au nombre de codespaces que vous pouvez exécuter en même temps. Si vous atteignez le nombre maximal de codespaces et que vous essayez d’en créer un autre, un message s’affiche vous indiquant que vous devez supprimer un codespace existant avant de pouvoir en créer un.

Processus de création d’un codespace

Quand vous créez un codespace, différentes étapes se produisent en arrière-plan avant que le codespace ne soit disponible.

Étape 1 : Une machine virtuelle et un stockage sont attribués à votre codespace

Lorsque vous créez un codespace, un ordinateur virtuel est créée à l’aide de la version stable ou bêta de l’image hôte de l’ordinateur virtuel. Pour plus d’informations, consultez « Choix de l’image hôte stable ou bêta ». L’image hôte définit la version de Linux utilisée pour l’ordinateur virtuel. L’ordinateur virtuel vous est à la fois dédiée et privée. Le fait que cette machine virtuelle vous soit dédiée vous permet de disposer de l’ensemble de ses ressources de calcul. Si nécessaire, cela vous permet également d’avoir un accès racine complet à votre conteneur.

Quand vous créez un codespace, un clone superficiel est créé à partir de votre référentiel ou du référentiel de modèles si vous créez un codespace à partir d’un modèle. Il est cloné dans le /workspaces répertoire de l’ordinateur virtuel et monté ultérieurement dans le conteneur de développement. Pour plus d’informations, consultez « À propos de la structure de répertoires d’un codespace » ci-dessous.

Étape 2 : Un conteneur de développement est créé

GitHub Codespaces utilise un conteneur docker comme environnement de développement. Ce conteneur est créé en fonction de configurations que vous pouvez définir dans un fichier devcontainer.json et, éventuellement, un fichier Dockerfile. Si vous créez un codespace à partir du modèle vide de GitHub, ou à partir d’un dépôt sans fichier devcontainer.json, GitHub Codespaces utilise une image par défaut, pour laquelle de nombreux langages et runtimes sont disponibles. Pour plus d’informations, consultez « Présentation des conteneurs de développement ». Pour plus de détails sur le contenu de l’image par défaut du conteneur de développement, consultez le référentiel devcontainers/images.

Remarque : si vous souhaitez utiliser des crochets Git dans votre codespace et appliquer le contenu du répertoire de modèles Git à votre codespace, vous devez configurer des crochets à l’étape 4 après la création du conteneur.

Étant donné que votre référentiel est cloné sur la machine virtuelle hôte avant la création du conteneur, le contenu du répertoire de modèles Git ne s’applique pas à votre codespace, sauf si vous configurez des crochets dans votre fichier de configuration devcontainer.json à l’aide de la commande postCreateCommand à l’étape 4. Pour plus d’informations, consultez « Étape 4 : Configuration post-création ».

Étape 3 : Connexion au codespace

Une fois votre conteneur créé et toute autre initialisation exécutée, vous être connecté à votre codespace. Vous pouvez vous y connecter avec :

Étape 4 : Configuration post-création

Une fois que vous êtes connecté à votre codespace, la configuration automatisée peut se poursuivre sur la base de la configuration spécifiée dans votre fichier devcontainer.json. Vous pouvez voir l’exécution des commandes postCreateCommand et postAttachCommand.

Si vous souhaitez utiliser des crochets Git dans votre codespace, configurez les crochets avec des scripts de cycle de vie devcontainer.json, comme postCreateCommand. Pour plus d’informations sur les scripts de cycle de vie, consultez la spécification des conteneurs de développement sur le site web Conteneurs de développement.

Si vous disposez d’un dépôt de fichiers dotfile public pour GitHub Codespaces, vous pouvez l’activer afin de l’utiliser avec de nouveaux espaces de code. Lorsque celui-ci est activé, vos dotfiles sont clonés dans le conteneur et le script d’installation est appelé. Pour plus d’informations, consultez « Personnalisation de GitHub Codespaces pour votre compte ».

Enfin, si vous avez créé le codespace à partir d’un dépôt, l’historique complet du dépôt est copié avec un clone complet. Si vous avez créé le codespace à partir d’un modèle, l’historique complet du dépôt de modèles n’est pas conservé ; à la place, sauf si vous utilisez le modèle vide, vous commencez par un commit initial pour le contenu du dépôt de modèles.

Lors de la configuration post-création, vous pourrez toujours utiliser le terminal intégré et apporter des modifications à vos fichiers, mais veillez alors à éviter toute condition de concurrence entre votre travail et les commandes en cours d’exécution.

Cycle de vie des Codespaces

Enregistrement de fichiers dans votre codespace

Enregistrez les modifications apportées aux fichiers de manière normale, en fonction de l’éditeur que vous utilisez.

Si vous travaillez sur des codespaces dans Visual Studio Code, vous pouvez activer l’enregistrement automatique pour vous assurer que vos modifications sont toujours enregistrées.

Fermeture ou arrêt de votre codespace

Votre codespace continue de s’exécuter pendant que vous l’utilisez, mais expire après une période d’inactivité. Les modifications apportées aux fichiers à partir de l’éditeur et de la sortie du terminal sont comptabilisées en tant qu’activité. Votre codespace n’expire donc pas si la sortie du terminal se poursuit. La période du délai d’inactivité par défaut est de 30 minutes. Vous pouvez définir votre paramètre de délai d’expiration personnel pour les codespaces que vous créez, mais cela peut être annulé par une stratégie de délai d’expiration de l’organisation. Pour plus d’informations, consultez « Définition de votre délai d'expiration pour GitHub Codespaces ».

Si un codespace expire, il cesse de s’exécuter, mais vous pouvez le redémarrer à partir de l’onglet du navigateur (si vous utilisiez le codespace dans le navigateur), de VS Code ou de votre liste de codespaces à l’adresse https://github.com/codespaces.

Pour arrêter votre codespace, vous pouvez

Dans le navigateur : dans votre liste de codespaces à l’adresse https://github.com/codespaces, cliquez sur les points de suspension ( ... ) à droite du codespace que vous souhaitez arrêter, puis cliquez sur Arrêter le codespace.
Dans VS Code : ouvrez la Visual Studio Code Command Palette : par exemple, en appuyant sur Ctrl+Maj+P (Windows/Linux) ou Maj+Commande+P (Mac) et tapez Codespaces: stop, puis appuyez sur Entrée. Pour plus d’informations, consultez « Utilisation de la palette de commandes de code Visual Studio dans GitHub Codespaces ».
Dans le client JetBrains, cliquez sur le bouton Arrêter en haut de la fenêtre d’outils GitHub Codespaces. Pour plus d’informations, consultez l’onglet « IDE JetBrains » dans « Arrêt et démarrage d’un codespace ».
Dans une fenêtre de terminal : utilisez la commande GitHub CLI gh codespace stop. Pour plus d’informations, consultez « Utilisation de GitHub Codespaces avec l’interface CLI de GitHub ».

Si vous quittez votre codespace sans exécuter la commande d’arrêt (par exemple, en fermant l’onglet du navigateur), ou si vous laissez le codespace s’exécuter sans interaction, le codespace et ses processus en cours continuent pendant la durée du délai d’inactivité.

Lorsque vous fermez ou arrêtez votre codespace, toutes les modifications non validées sont conservées jusqu’à ce que vous vous connectiez à nouveau au codespace.

Exécution de votre application

Le réacheminement de ports vous permet d’accéder aux ports TCP exécutés dans votre codespace. Par exemple, si vous exécutez une application web sur le port 4000 de votre codespace, vous pouvez réacheminer automatiquement ce port pour rendre l’application accessible à partir de votre navigateur.

Le réacheminement de port détermine les ports accessibles à partir de l’ordinateur distant. Même si vous ne réacheminez pas un port, celui-ci reste accessible aux autres processus qui s’exécutent dans le codespace lui-même.

Diagramme montrant les connexions, via Internet, entre un éditeur de code ou un navigateur sur votre appareil et un codespace sur le cloud.

Quand une application exécutée dans GitHub Codespaces envoie un port vers la console, GitHub Codespaces détecte le modèle d’URL localhost et réachemine automatiquement le port. Vous pouvez cliquer sur l’URL dans le terminal ou sur le lien dans le message de notification « toast » qui s’affiche en bas à droite de VS Code, pour ouvrir le port dans un navigateur. Par défaut, GitHub Codespaces réachemine le port à l’aide de HTTP. Pour plus d’informations sur le réacheminement de port, consultez « Transfert de ports dans votre espace de code ».

Bien que les ports puissent être réacheminés automatiquement, ils ne sont pas accessibles publiquement sur Internet. Par défaut, tous les ports sont privés, mais vous pouvez manuellement rendre un port public ou disponible à l’échelle de votre organisation, puis partager l’accès via une URL. Pour plus d’informations, consultez « Transfert de ports dans votre espace de code ».

L’exécution de votre application dès votre arrivée dans votre codespace peut constituer une boucle de développement interne rapide. Au fil de vos modifications, celles-ci sont automatiquement enregistrées et disponibles sur votre port réacheminé. Pour visualiser les modifications, revenez à l’onglet de l’application en cours d’exécution dans votre navigateur et actualisez-le.

Validation (commit) et envoi (push) de vos modifications

Git est installé par défaut dans votre codespace. Vous pouvez donc vous appuyer sur votre workflow Git existant. Vous pouvez utiliser Git dans votre codespace via le terminal ou en utilisant les fonctionnalités de contrôle de code source de VS Code ou JetBrains.

Si vous utilisez un dépôt existant, vous pouvez créer un codespace à partir de n’importe quelle branche, commit ou demande de tirage (pull request) du dépôt, ou basculer vers une branche nouvelle ou existante à partir de votre codespace actif. Dans la mesure où GitHub Codespaces est conçu pour être éphémère, vous pouvez l’utiliser comme un environnement isolé pour effectuer des expériences, vérifier la demande de tirage d’un collègue ou résoudre des conflits de fusion.

Si vous disposez uniquement d’un accès en lecture à un dépôt, vous pouvez alors créer un codespace pour le dépôt, à condition que vous puissiez le dupliquer. Lorsque vous effectuez un commit à partir du codespace, ou pousser une nouvelle branche, GitHub Codespaces crée automatiquement une duplication du dépôt pour vous, ou lie le codespace à une duplication existante si vous en avez déjà une pour le dépôt en amont.

Si vous travaillez dans un codespace créé à partir d’un modèle, Git est installé par défaut, mais vous devez publier votre codespace dans un dépôt distant pour conserver votre travail et le partager avec d’autres personnes. Si vous commencez à partir du modèle vide de GitHub, vous devez d’abord initialiser votre espace de travail en tant que dépôt Git (par exemple en entrant git init) pour commencer à utiliser le contrôle de code source dans le codespace.

Pour plus d’informations, consultez « Utilisation du contrôle de code source dans votre espace de code ».

Remarque : les validations de votre codespace sont attribuées au nom et à l’adresse e-mail publique configurés à l’adresse https://github.com/settings/profile. Un jeton étendu au référentiel, inclus dans l’environnement sous le nom de GITHUB_TOKEN, et vos informations d’identification GitHub seront utilisées pour l’authentification.

Personnalisation de votre codespace avec des extensions ou plug-ins

Vous pouvez ajouter des plug-ins et des extensions dans un codespace pour personnaliser votre expérience dans JetBrains et VS Code respectivement.

Extensions VS Code

Si vous travaillez sur vos codespaces dans l’application de bureau VS Code ou dans le client web, vous pouvez ajouter toutes les extensions dont vous avez besoin à partir de la Visual Studio Code Marketplace. Pour plus d’informations sur l’exécution des extensions dans GitHub Codespaces, consultez Prise en charge du développement à distance et de GitHub Codespaces dans la documentation VS Code.

Si vous utilisez déjà VS Code, vous pouvez utiliser la fonctionnalité Synchronisation des paramètres pour synchroniser automatiquement les extensions, les paramètres, les thèmes et les raccourcis clavier entre votre instance locale et tous les codespaces que vous créez.

Plug-ins JetBrains

Si vous travaillez sur vos codespaces dans un IDE JetBrains, vous pouvez ajouter des plug-ins à partir de la Place de marché JetBrains.

Cliquez sur JetBrains Client (Client JetBrains), puis sur Preferences.
Dans la boîte de dialogue Preferences, cliquez sur Plugins On Host pour installer un plug-in dans l’IDE JetBrains complet qui s’exécute à distance, ou sur Plugins pour installer un plug-in sur le client local, par exemple pour changer le thème de l’interface utilisateur.
Cliquez sur l’onglet Marketplace (Place de marché).
Cliquez sur Install à côté du plug-in requis.

À propos de la structure de répertoires d’un codespace

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 faire des changements dans des fichiers en dehors du répertoire /workspaces : par exemple, vous pouvez installer de nouveaux programmes, ou vous pouvez configurer votre interpréteur de commandes dans un fichier de type ~/.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 le répertoire /tmp, consultez « Persistance des variables d’environnement et des fichiers temporaires ».

L’effacement des répertoires en dehors de /workspaces aide à s’assurer que le conteneur regénéré est dans le même état que dans un codespace nouvellement créé. Si vous regénérez un conteneur pour appliquer des modifications de configuration au codespace dans lequel vous travaillez, vous pouvez être certain que toutes les modifications de configuration que vous avez apportées fonctionneront de la même façon pour les utilisateurs qui créent des codespaces avec la même configuration. Pour plus d’informations, consultez « Présentation des conteneurs de développement ».

Si vous souhaitez apporter des modifications à votre codespace qui soient plus robustes par rapport aux regénérations et dans différents codespaces, vous avez plusieurs options.

Pour installer des programmes et des outils dans tous les codespaces créés à partir d’un dépôt, dans la configuration de votre conteneur de développement, vous pouvez utiliser des propriétés de commande de cycle de vie telles que postCreateCommand pour exécuter des commandes d’installation personnalisées, ou vous pouvez choisir parmi des commandes d’installation préécrites appelées « fonctionnalités ». Pour plus d’informations, consultez la spécification sur les conteneurs de développement sur le site web Conteneurs de développement et « Ajout de fonctionnalités à un fichier devcontainer.json ».
Pour installer des outils ou personnaliser votre configuration dans chaque codespace que vous créez, comme la configuration de votre profil bash, vous pouvez lier GitHub Codespaces à un dépôt dotfiles. Le dépôt dotfiles est également cloné dans le répertoire /workspaces persistant. Pour plus d’informations, consultez « Personnalisation de GitHub Codespaces pour votre compte ».
Si vous souhaitez conserver des fichiers spécifiques lors d’une regénération, vous pouvez utiliser un fichier devcontainer.json pour créer un lien symbolique entre les fichiers et un répertoire persistant dans /workspaces. Pour plus d’informations, consultez « Regénération du conteneur dans un codespace ».