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 référentiel de modèles sur GitHub 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, afin d'analyser un bogue à un moment précis.

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.

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 espace de code, une machine virtuelle (VM) est générée à l’aide de la version stable ou préversion publique de l’image hôte de la VM. 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. La machine virtuelle vous est 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.

Un clone superficiel est ensuite créé à partir de votre dépôt ou du dépôt 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.

Étape 3 : Connexion au codespace

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

• Votre navigateur web

•         [Visual Studio Code](/codespaces/developing-in-a-codespace/using-github-codespaces-in-visual-studio-code)
  

•         [GitHub CLI](/codespaces/developing-in-a-codespace/using-github-codespaces-with-github-cli)
  

É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 hooks Git dans votre environnement de code, configurez les hooks avec les 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 « Personnaliser 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 clonage intégral. 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 période d’expiration pour GitHub Espaces de code ».

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 le Visual Studio Code Command Palette - par exemple, en appuyant sur Ctrl+Shift+P (Windows/Linux) ou Shift+Command+P (Mac) - tapez Codespaces: stop puis appuyez sur Entrée. Pour plus d’informations, consultez « Utilisation de la palette de commandes Visual Studio Code dans GitHub Espaces de code ».
• Dans une fenêtre de terminal : utilisez la commande GitHub CLI gh codespace stop. Pour plus d’informations, consultez « Utilisation de GitHub Codespaces avec GitHub CLI ».

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

La redirection de ports vous permet d’accéder aux ports TCP qui s'exécutent 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.

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 transfert 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.

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 mener des expériences, vérifier le pull request 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 que vous poussez une nouvelle branche, GitHub Codespaces crée automatiquement un fork du dépôt pour vous, ou lie le codespace à un fork existant si vous en avez déjà un 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 ».

Personnalisation de votre codespace avec des extensions

Vous pouvez ajouter des extensions dans un codespace pour personnaliser votre expérience dans VS Code.

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 obtenir des informations sur l’exécution des extensions dans GitHub Codespaces, consultez la section Soutien au développement à distance et à GitHub Codespaces dans la documentation de 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.

À 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 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 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 lors des reconstructions et entre différents codespaces, plusieurs options s'offrent à vous.

• 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 « Personnaliser 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 « Reconstruction du conteneur dans un espace de code ».

Pour aller plus loin

•         [AUTOTITLE](/codespaces/managing-codespaces-for-your-organization/enabling-or-disabling-github-codespaces-for-your-organization)
  

•         [AUTOTITLE](/codespaces/managing-codespaces-for-your-organization/managing-the-cost-of-github-codespaces-in-your-organization)
  

•         [AUTOTITLE](/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration)
  

•         [AUTOTITLE](/codespaces/about-codespaces/understanding-the-codespace-lifecycle)