Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Restriction de la période du délai d’inactivité

Vous pouvez définir un délai d’expiration maximal pour tous les codespaces appartenant à votre organisation.

Qui peut utiliser cette fonctionnalité

To manage timeout constraints for an organization's codespaces, you must be an owner of the organization.

Les organisations sur les plans GitHub Team et GitHub Enterprise peuvent activer l’utilisation de GitHub Codespaces, facturable à l’organisation. Ces organisations peuvent ensuite accéder aux paramètres qui s’appliquent aux codespaces payés par l’organisation. Pour plus d’informations, consultez « Activation de GitHub Codespaces pour votre organisation » et « Produits de GitHub ».

Vue d’ensemble

Par défaut, les espaces de code expirent après 30 minutes d’inactivité. Lorsqu’un espace de code expire, il est arrêté et n’entraîne plus de frais pour l’utilisation du calcul.

Les paramètres personnels d’un utilisateur GitHub lui permettent de définir sa propre période d’expiration pour les espaces de code qu’il crée. Cela peut être plus long que la période par défaut de 30 minutes. Pour plus d’informations, consultez « Définition de votre délai d’expiration pour GitHub Codespaces ».

En tant que propriétaire de l’organisation, vous pouvez configurer des contraintes sur le délai d’inactivité maximal pour les codespaces qui appartiennent à votre organisation. Cela peut vous aider à limiter les coûts associés aux espaces de code que vous laissez expirer après de longues périodes d’inactivité. Vous pouvez définir un délai d’expiration maximal pour les codespaces de tous les dépôts appartenant à votre organisation ou pour ceux situés dans certains dépôts.

Remarque : Les contraintes de délai d’inactivité maximales s’appliquent uniquement aux espaces de code appartenant à votre organisation.

Pour plus d’informations sur les tarifs appliqués pour l’utilisation du calcul de GitHub Codespaces, consultez « À propos de la facturation pour GitHub Codespaces ».

Comportement lorsque vous définissez une contrainte de délai d’inactivité maximale

Si une personne définit le délai d’inactivité par défaut sur 90 minutes dans ses paramètres personnels, puis démarre un espace de code pour un référentiel avec une contrainte de délai d’inactivité maximale de 60 minutes, l’espace de code expire après 60 minutes d’inactivité. Une fois la création de l’espace de code terminée, un message expliquant cela s’affiche :

Le délai d’inactivité de cet espace de code est défini sur 60 minutes en conformité avec la stratégie de votre organisation.

Définition de stratégies spécifiques à l’organisation et au référentiel

Lorsque vous créez une stratégie, vous choisissez si elle s’applique à tous les référentiels de votre organisation ou uniquement aux référentiels spécifiés. Si vous créez une stratégie à l’échelle de l’organisation avec une contrainte de délai d’expiration, les contraintes de délai d’expiration dans toutes les stratégies ciblant des référentiels spécifiques doivent se trouver dans la restriction configurée pour l’ensemble de l’organisation. La période d’expiration la plus courte (dans une stratégie à l’échelle de l’organisation, une stratégie ciblée sur les référentiels spécifiés ou dans les paramètres personnels d’une personne) est appliquée.

Si vous ajoutez une stratégie à l’échelle de l’organisation avec une contrainte de délai d’expiration, vous devez définir le délai d’expiration sur la période acceptable la plus longue. Vous pouvez ensuite ajouter des stratégies distinctes qui définissent le délai d’expiration maximal sur une période plus courte pour des référentiels spécifiques dans votre organisation.

Remarque : Les stratégies de codespace s’appliquent uniquement aux codespaces pour lesquels votre organisation est facturée. Si un utilisateur individuel crée un codespace pour un dépôt inclus dans votre organisation et que l’organisation n’est pas facturée, alors le codespace n’est pas lié par ces stratégies. Pour plus d’informations sur la façon de choisir qui peut créer des codespaces facturés à votre organisation, consultez « Activation de GitHub Codespaces pour votre organisation ».

Ajout d’une stratégie pour définir un délai d’inactivité maximal

  1. Dans l’angle supérieur droit de GitHub.com, cliquez sur votre photo de profil, puis sur Vos organisations.

    Capture d’écran du menu déroulant sous l’image de profil de @octocat. « Vos organisations » est présenté en orange foncé. 2. En regard de l’organisation, cliquez sur Paramètres.

    Capture d’écran de l’organisation « octo-org » avec le bouton « Paramètres » mis en évidence avec un contour orange foncé. 1. Dans la section « Code, planification et automatisation » de la barre latérale, sélectionnez Codespaces puis cliquez sur Stratégies.

  2. Dans la page « Stratégies d’espace de code », cliquez sur Créer une stratégie.

  3. Entrez un nom pour votre nouvelle stratégie.

  4. Cliquez sur Ajouter une contrainte et choisissez Délai d’inactivité maximal.

  5. Cliquez sur pour modifier la contrainte.

  6. Entrez le nombre maximal de minutes pendant lesquelles les espaces de code peuvent rester inactifs avant d’expirer, puis cliquez sur Enregistrer.

    Capture d’écran d’une liste déroulante avec un champ intitulé « Valeur maximale » défini sur 60 minutes. À droite du champ se trouve un bouton « Enregistrer ».

  7. Cliquez en dehors de la boîte de dialogue pour la fermer.

  8. Par défaut, la stratégie est définie pour s’appliquer à tous les dépôts. Si vous souhaitez qu’elle s’applique uniquement à certains des dépôts de votre organisation, cliquez sur Tous les dépôts, puis sur Dépôts sélectionnés dans le menu déroulant.

    Capture d’écran de la liste déroulante de sélection des référentiels, montrant les options « Tous les référentiels » et « Référentiels sélectionnés ».

    Avec le choix Dépôts sélectionnés :

    1. Cliquez sur .

      Capture d’écran de l’icône des paramètres (symbole d’engrenage) à gauche d’un bouton intitulé « Référentiels sélectionnés ».

    2. Sélectionnez les dépôts auxquels vous souhaitez appliquer cette stratégie.

    3. En bas de la liste des dépôts, cliquez sur Sélectionner des dépôts.

      Capture d’écran d’une liste de référentiels, chacun avec une case à cocher. Trois référentiels sont sélectionnés.

  9. Pour ajouter une autre contrainte à la stratégie, cliquez sur Ajouter une contrainte et choisissez une autre contrainte. Pour plus d’informations sur les autres contraintes, consultez :

  10. Une fois que vous avez terminé d’ajouter des contraintes à votre stratégie, cliquez sur Enregistrer.

La stratégie sera appliquée à tous les nouveaux codespaces facturables à votre organisation. La contrainte d’expiration est également appliquée aux codespaces existants lors de leur prochain démarrage.

Modification d’une stratégie

Vous pouvez modifier une stratégie existante. Par exemple, vous avez peut-être besoin d’ajouter ou de supprimer des contraintes dans une stratégie.

  1. Affichez la page « Stratégies d’espace de code ». Pour plus d’informations, consultez « Ajout d’une stratégie pour définir une période d’inactivité maximale ».
  2. Cliquez sur le nom de la stratégie à modifier.
  3. À côté de la contrainte « Période d’inactivité maximale », cliquez sur .
  4. Apportez les changements nécessaires, puis cliquez sur Enregistrer.

Suppression d’une stratégie

  1. Affichez la page « Stratégies d’espace de code ». Pour plus d’informations, consultez « Ajout d’une stratégie pour définir une période d’inactivité maximale ».

  2. Cliquez sur le bouton Supprimer à droite de la stratégie à supprimer.

    Capture d’écran d’une stratégie avec le bouton Supprimer (icône corbeille) mis en surbrillance avec un contour orange foncé.