Skip to main content

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

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. 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 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. Consultez « À 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

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

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

    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.

    Note

    Toutes les branches créées à partir d’une branche de base activée pour les pré-générations obtiendront également des pré-générations 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.

  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

        Note

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

      • Dockerfile 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.

    Note

  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 défini sur 2 versions.

    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. Consultez « À propos de la facturation pour GitHub Codespaces ».

  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.

    Note

    Les personnes recevront les notifications de pré-générations ayant échoué uniquement si elles ont activé les notifications pour les workflows d’actions ayant échoué 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.

    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.

    Capture d’écran d’une page d’autorisation pour une configuration de prébuild. Trois autorisations sont listées dans cette demande.

    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.

    Note

    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.

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

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

Pour aller plus loin