Configuration des prébuilds

Vous pouvez configurer votre projet pour prédéfinir automatiquement un espace de code chaque fois que vous envoyez une modification à votre référentiel.

Qui peut utiliser cette fonctionnalité ?

People with admin access to a repository can configure prebuilds for the repository.

Les paramètres au niveau du dépôt de GitHub Codespaces sont disponibles pour tous les dépôts appartenant à des comptes personnels.

Pour les dépôts appartenant à des organisations, les paramètres au niveau du dépôt de GitHub Codespaces sont disponibles pour les organisations sur les plans GitHub Team et GitHub Enterprise. Pour accéder aux paramètres, l’organisation ou son entreprise parente doit avoir ajouté un mode de paiement et défini une limite de dépense pour GitHub Codespaces. Pour plus d’informations, consultez « Choisir qui possède et achète les codespaces dans votre organisation » et « plans de GitHub ».

Dans cet article

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, les prébuilds pour les branches enfants qui utilisent la même configuration de conteneur de développement que la branche parente sont, pour la plupart, identiques, pour que les développeurs puissent bénéficier de temps de création de codespace plus rapides sur ces branches également. Consultez « 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. Consultez « Gestion des paramètres de GitHub Actions pour un référentiel ».

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.

Remarque

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. Consultez facturation des Codespaces GitHub.

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 Configurer des budgets pour contrôler les dépenses liées aux produits facturés à l’usage et plans de GitHub.

Configuration des prébuilds

  1. Sur GitHub, accédez à la page principale du référentiel.

  2. Sous le nom de votre référentiel, cliquez sur Paramètres. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.

    Capture d’écran d’un en-tête de dépôt montrant les onglets. L’onglet « Paramètres » est mis en évidence avec un encadré orange foncé.

  3. Dans la section « Code et automatisation » de la barre latérale, cliquez sur Codespaces.

  4. Dans la section « Configuration de prébuild » de la page, cliquez sur Configurer la prébuild.

    Capture d’écran de la section « Configuration de prébuild » de la page de paramètres « Codespaces », montrant le bouton « Configurer la prébuild ».

  5. Choisissez la branche pour laquelle vous souhaitez configurer des prébuilds.

    Capture d’écran des paramètres « Configuration » d’une prébuild avec un menu déroulant listant les branches à sélectionner. La branche « main » est actuellement sélectionnée.

    Remarque

    Toutes les branches créées à partir d’une branche de base préconfigurée bénéficieront généralement aussi de préconfigurations pour la même configuration de conteneur de développement. Par exemple, si vous activez les pré-compilations pour un fichier de configuration de conteneur de développement sur la branche par défaut du dépôt, les branches basées sur la branche par défaut bénéficieront également, dans la plupart des cas, de pré-compilations pour la même configuration de conteneur de développement.

  6. Si vous le souhaitez, dans le menu déroulant Fichier de configuration qui s’affiche, choisissez le fichier de configuration devcontainer.json que vous souhaitez utiliser pour vos prébuilds. Consultez « Présentation des conteneurs de développement ».

    Capture d’écran du menu déroulant du fichier de configuration. Quatre fichiers de configuration sont listés, avec « .devcontainer/devcontainer.json » actuellement sélectionné.

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

        Remarque

        Les mises à jour de précompilation ne sont pas déclenchées par les modifications apportées aux fichiers devcontainer.json dans les sous-répertoires de .devcontainer.

      • Le fichier Dockerfile est référencé dans la propriété build.dockerfile du 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.

    Capture d’écran des paramètres « Déclencheurs de prébuild ». L’option « Planifié » est sélectionnée et définie sur « Tous les jours » à « 13h » et « 15h30 ».

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

    Capture d’écran des paramètres « Disponibilité des régions ». « Réduire la disponibilité des prébuilds à des régions spécifiques » est sélectionné avec deux régions sélectionnées.

    Remarque

    • La précompilation dans chaque région génère des frais de stockage spécifiques. Vous ne devez donc activer les prébuilds que pour les régions dans lesquelles vous savez qu’elles seront utilisées.
    • 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. Consultez « Définition de votre région par défaut pour GitHub Espaces de code ».

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

    Capture d’écran du paramètre « Historique des modèles ». Il est réglé sur 2 versions.

    En fonction de vos paramètres de déclencheur de prébuild, votre prébuild peut être modifié à chaque push ou à chaque changement de configuration du 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. Consultez « facturation des Codespaces GitHub ».

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

    Capture d’écran du paramètre « Notifications d’échec ». L’équipe nommée « octocat-team » a été ajoutée.

    Remarque

    Les utilisateurs recevront des notifications d’échec de préconfiguration uniquement s’ils ont activé les notifications d’échec des workflows Actions dans leurs paramètres personnels. Consultez « Configuration des notifications ».

  11. Si vous le souhaitez, en bas de la page, cliquez sur Afficher les options avancées.

    Capture d’écran du bas de la page de configuration des prébuilds. Le lien « Afficher les options avancées » est mis en évidence avec un encadré orange foncé.

    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. Consultez « Résolution des problèmes liés aux prébuilds ».

  12. Cliquez sur Créer.

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.

Capture d’écran de la liste des configurations prédéfinies. Une préconstruction est répertoriée, intitulée « En cours d’exécution actuellement ». À droite de celui-ci se trouve un bouton « Voir la sortie ».

Pour plus d’informations sur la modification et la suppression des configurations de prebuild, 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. Consultez « 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é-construction

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.

Pour aller plus loin

  •         [AUTOTITLE](/codespaces/prebuilding-your-codespaces/allowing-a-prebuild-to-access-other-repositories)

  •         [AUTOTITLE](/codespaces/troubleshooting/troubleshooting-prebuilds)