Vous pouvez configurer une configuration de prébuild pour combiner une branche spécifique de votre dépôt avec un fichier de configuration de conteneur de développement spécifique.
Toutes les branches créées à partir d’une branche parente activée par prébuild obtiennent généralement des prébuilds pour la même configuration de conteneur de développement. En effet, la prébuild pour les branches enfants qui utilisent la même configuration de conteneur de développement que la branche parente est, pour une grande partie, identique, afin que les développeurs puissent bénéficier d’un temps de création de codespace plus rapide sur ces branches également. Consulter « Présentation des conteneurs de développement ».
En règle générale, lorsque vous configurez des prébuilds pour une branche, celles-ci sont disponibles pour plusieurs types de machines. Toutefois, si votre référentiel fait plus de 32 Go, les prébuilds ne seront pas disponibles pour les types de machines 2 cœurs et 4 cœurs, car le stockage qu’elles fournissent est limité à 32 Go.
Prérequis
Les prébuilds sont créées avec GitHub Actions. GitHub Actions doit donc être activé pour le dépôt pour lequel vous configurez des prébuilds. Consulter « Gestion des paramètres de GitHub Actions pour un dépôt ».
Vous pouvez configurer des prébuilds dans n’importe quel dépôt appartenant à un compte personnel. La prébuild consomme de l’espace de stockage qui entraîne des frais facturables ou, pour les dépôts appartenant à votre compte personnel, utilise une partie de votre stockage mensuel inclus.
Note : Si vous créez des prébuilds pour un référentiel duplique, le coût de stockage de ces prébuilds est soustrait de votre stockage inclus mensuel, alors qu’il est disponible. Si vous avez utilisé l’ensemble de votre stockage inclus et que vous avez configuré la facturation, votre compte personnel est facturé. Cela est vrai même lorsque les codespaces que vous créez pour un fork sont payés par l’organisation propriétaire du dépôt parent. Voir « À propos de la facturation pour GitHub Codespaces ».
Pour les dépôts appartenant à une organisation, vous pouvez configurer des prébuilds si celle-ci est sur un plan GitHub Team ou GitHub Enterprise. En outre, vous devez avoir ajouté un mode de paiement et défini une limite de dépense pour GitHub Codespaces sur le compte d’organisation ou son entreprise parente. Consultez « Gestion de la limite de dépense pour GitHub Codespaces » et « Plans de GitHub. »
Configuration des prébuilds
-
Sur GitHub, accédez à la page principale du référentiel.
-
Sous le nom de votre dépôt, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.
-
Dans la section « Code et automatisation » de la barre latérale, cliquez sur Codespaces .
-
Dans la section « Configuration de prébuild » de la page, cliquez sur Configurer la prébuild.
-
Choisissez la branche pour laquelle vous souhaitez configurer des prébuilds.
Remarque :Toutes les branches créées à partir d’une branche de base activée par prébuild obtiennent généralement des prébuilds pour la même configuration de conteneur de développement. Par exemple, si vous activez les prébuilds pour un fichier de configuration de conteneur de développement sur la branche par défaut du dépôt, dans la plupart des cas, vous obtenez aussi les prébuilds pour la même configuration de conteneur de développement.
-
Si vous le souhaitez, dans le menu déroulant Fichier de configuration qui s’affiche, choisissez le fichier de configuration
devcontainer.jsonque vous souhaitez utiliser pour vos prébuilds. Consulter « Présentation des conteneurs de développement ».
-
Choisissez la façon dont vous souhaitez déclencher automatiquement les mises à jour des prébuilds.
-
À chaque envoi (paramètre par défaut) : avec ce paramètre, les prébuilds sont mises à jour à chaque envoi (push) vers la branche donnée. Vous avez ainsi la certitude que les codespaces générés à partir d’une prébuild contiennent toujours la dernière configuration de codespace, ainsi que les dépendances récemment ajoutées ou mises à jour.
-
En cas de modification de la configuration - Avec ce paramètre, les prébuilds sont mises à jour à chaque fois que l’un des fichiers suivants est modifié :
-
.devcontainer/devcontainer.jsonRemarque : Les mises à jour des prébuilds ne sont pas déclenchées par les modifications apportées aux fichiers
devcontainer.jsondans les sous-répertoires de.devcontainer. -
Dockerfile référencé dans la propriété
build.dockerfiledu fichier.devcontainer/devcontainer.json.
Ce paramètre garantit que les modifications apportées aux fichiers de configuration du conteneur de développement pour le dépôt sont utilisées quand un codespace est généré à partir d’une prébuild. Le workflow GitHub Actions qui met à jour les prébuilds s’exécute moins souvent. Cette option utilise donc moins de minutes GitHub Actions. Toutefois, cette option ne garantit pas que les codespaces incluront toujours des dépendances récemment ajoutées ou mises à jour. Celles-ci peuvent donc être ajoutées ou mises à jour manuellement après la création d’un codespace.
-
-
Mise à jour planifiée : avec ce paramètre, vous pouvez mettre à jour vos prébuilds selon une planification personnalisée définie par vous. Cela peut réduire la consommation des minutes GitHub Actions. Toutefois, avec cette option, des codespaces n’utilisant pas les dernières modifications de la configuration de conteneur de développement peuvent être créés.
-
-
Si vous le souhaitez, sélectionnez Réduire la disponibilité des prébuilds à des régions spécifiques pour créer des prébuilds uniquement dans les régions spécifiées. Sélectionnez les régions dans lesquelles vous souhaitez que les prébuilds soient disponibles.
Par défaut, les prébuilds sont créées dans toutes les régions disponibles, ce qui entraîne des frais de stockage par prébuild.
Remarques:
- La prébuild dans chaque région entraîne des frais de stockage individuels. Vous ne devez donc activer les prébuilds que pour les régions dans lesquelles vous savez qu’elles seront utilisées. Consulter « À propos de la facturation pour GitHub Codespaces ».
- Les développeurs peuvent définir leur région par défaut pour GitHub Codespaces, ce qui permet d’activer les prébuilds pour un plus petit nombre de régions. Consulter « Définition de votre région par défaut pour GitHub Codespaces ».
-
Si vous le souhaitez, sous Historique des modèles, définissez le nombre de versions de prébuild à conserver. Vous pouvez entrer n’importe quel nombre compris entre 1 et 5. Le nombre par défaut de versions enregistrées est de 2, ce qui signifie que seules la dernière prébuild et la version précédente sont enregistrées.
En fonction de vos paramètres de déclencheur de prébuild, votre prébuild peut changer avec chaque modification push ou sur chaque modification de configuration de conteneur de développement. La conservation des versions antérieures des prébuilds vous permet de créer une prébuild à partir d’une validation antérieure avec une configuration de conteneur de développement différente de celle de la prébuild actuelle. Ce paramètre vous permet de définir le nombre de versions conservées à un niveau adapté à vos besoins.
Si vous définissez le nombre de versions de prébuilds à enregistrer sur 1, GitHub Codespaces enregistre uniquement la dernière version de la prébuild et supprime l’ancienne version chaque fois que le modèle est mis à jour. Cela signifie que vous n’obtiendrez pas d’espace de code prédéfini si vous revenez à une configuration de conteneur de développement plus ancienne.
Un coût de stockage est associé à chaque version de prébuild conservée. Par exemple, si vous générez des prébuilds dans 4 régions et conservez 2 versions, vous serez facturé pour le stockage de 8 prébuilds au maximum. Consulter « À propos de la facturation pour GitHub Codespaces ».
-
Ajoutez éventuellement des utilisateurs ou des équipes à avertir quand l’exécution du workflow de prébuild échoue pour cette configuration. Vous pouvez commencer à taper un nom d’utilisateur, un nom d’équipe ou un nom complet, puis cliquer sur le nom une fois qu’il apparaît pour les ajouter à la liste. Les utilisateurs ou les équipes que vous ajoutez recevront un e-mail lorsque des échecs de prébuild se produisent, avec un lien vers les journaux d’exécution du workflow pour faciliter l’examen approfondi.
Remarque : Les personnes reçoivent les notifications de prébuilds ayant échoué uniquement si elles ont activé les notifications pour les workflows d’actions ayant échoué dans leurs paramètres personnels. Consulter « Configuration des notifications ».
-
Si vous le souhaitez, en bas de la page, cliquez sur Afficher les options avancées.
Dans la section « Options avancées », si vous sélectionnez Désactiver l’optimisation de la prébuild, les codespaces sont créés sans prébuild si le dernier workflow de prébuild a échoué ou est en cours d’exécution. Consulter « Résolution des problèmes liés aux prébuilds ».
-
Cliquez sur Créer.
Si la configuration du conteneur de développement pour le dépôt spécifie des autorisations d’accès à d’autres dépôts, vous verrez une page d’autorisation s’afficher. Pour plus d’informations sur la façon de les spécifier dans le fichier
devcontainer.json, consultez « Gestion de l’accès à d’autres dépôts dans votre codespace ».Cliquez sur pour voir les détails des autorisations demandées.
Cliquez sur Autoriser et continuer pour accorder ces autorisations de création de prébuilds. Vous pouvez également cliquer sur Continuer sans autoriser, mais dans ce cas, les codespaces créés à partir des prébuilds obtenues peuvent ne pas fonctionner correctement.
Remarque : les utilisateurs qui créent des codespaces à l'aide de cette version pré-construite seront également invités à accorder ces autorisations.
Après la création d’une configuration de prébuild, celle-ci est listée dans la page GitHub Codespaces des paramètres de votre dépôt. Un workflow GitHub Actions est mis en file d’attente, puis exécuté pour créer des prébuilds dans les régions que vous avez spécifiées, en fonction de la branche et du fichier de configuration de conteneur de développement que vous avez sélectionnés.
Pour plus d’informations sur la modification et la suppression des configurations de prébuild, consultez « Gestion des prébuilds ».
Configuration des variables d’environnement
Pour permettre au processus de prébuild d’accéder aux variables d’environnement nécessaires à la création de votre environnement de développement, vous pouvez les définir sous la forme de secrets de référentiel Codespaces ou de secrets d’organisation Codespaces. Les secrets que vous créez de cette façon seront accessibles par toute personne qui crée un codespace à partir de ce dépôt. Consulter « Gestion des secrets d’environnement de développement pour votre référentiel ou votre organisation ».
Les prébuilds ne peuvent pas utiliser de secrets au niveau utilisateur lors de la création de votre environnement, car ceux-ci ne sont disponibles qu’après la création du codespace.
Configuration des tâches chronophages à inclure dans la prébuild
Vous pouvez utiliser les commandes onCreateCommand et updateContentCommand de votre devcontainer.json pour inclure les processus chronophages dans le cadre de la création de la prébuild. Consultez la documentation Visual Studio Code, « Informations de référence sur devcontainer.json ».
onCreateCommand ne s’exécute qu’une seule fois, lors de la création de la prébuild, tandis que updateContentCommand s’exécute lors de la création de la prébuild et de ses mises à jour ultérieures. Les builds incrémentielles doivent être incluses dans updateContentCommand, car elles représentent la source de votre projet et doivent être incluses pour chaque mise à jour de la prébuild.