Résumé

  • La durée de conservation d’un codespace est attribuée à sa création. Modifier ou supprimer la politique de l’organisation laisse intactes les durées des espaces existants.
  • Un espace arrêté continue de consommer du stockage. Sa suppression automatique peut emporter des modifications non poussées vers le dépôt ; réduire le parc demande donc un travail de sortie.

La capture d’écran est impeccable : sept jours de conservation au lieu de trente. Elle ferait une excellente pièce jointe au prochain point budgétaire. Il lui manque seulement une information assez embarrassante : à quels espaces cette économie s’applique-t-elle ?

Dans cet exemple de réglage, les nouveaux arrivants auront des conditions plus courtes. Les anciens occupants gardent les leurs. GitHub l’explique dans sa documentation des politiques de conservation : la durée est fixée lors de la création du codespace. Une modification ultérieure de la politique ne la change pas. Supprimer la politique ne la change pas davantage.

Voilà une règle qui protège la continuité des environnements existants et complique les promesses de nettoyage instantané. Le bouton fait bien son travail. C’est le compte rendu de la réunion qui risque de lui attribuer un deuxième métier.

Le placard a plusieurs générations

Un codespace conserve un environnement de développement dans le cloud. On peut l’arrêter puis le reprendre avec les fichiers enregistrés. Cette possibilité de retour est un service concret : elle évite de devoir tout remettre en place à chaque reprise.

Elle mobilise aussi une ressource. La description du cycle de vie distingue le calcul, consommé pendant l’exécution, du stockage, qui continue après l’arrêt. Ce dernier cesse de s’accumuler à la suppression. L’utilisation déjà comptabilisée dans le mois reste comptabilisée.

Un inventaire peut ainsi contenir des espaces soumis à d’anciennes durées, d’autres créés depuis le changement, et des espaces dont le compteur d’inactivité a redémarré après une reconnexion. Leur date de création ne suffit pas à dire lequel partira le premier. La politique du jour ne décrit pas, à elle seule, le parc du jour.

Le payeur compte également. Une politique d’organisation s’applique aux codespaces financés par cette organisation. Le simple fait que le dépôt lui appartienne ne place pas un espace payé personnellement sous ce régime. À la création, les différentes limites applicables, notamment celles de l’organisation, du dépôt et de l’utilisateur, conduisent à retenir la plus courte. L’organigramme des dépôts et celui des factures ne se superposent pas automatiquement.

Les documents publics ne donnent ni l’inventaire d’une entreprise, ni ses durées attribuées, ni son travail non poussé, ni sa facture : chiffrer son économie exige ces quatre éléments. Le mécanisme, lui, est assez net pour interdire de compter des suppressions que le nouveau paramètre n’a jamais ordonnées.

Le code peut rester dans le tiroir

La conservation d’un espace et celle d’un résultat de travail suivent des chemins différents. Enregistrer un fichier le laisse sur la machine virtuelle. Le déposer dans le dépôt distant suppose de le valider et de le pousser.

Cette séparation devient brutale à l’échéance. GitHub précise que la suppression automatique intervient même si des modifications n’ont pas été poussées. Le système vérifie son calendrier ; il ne sait pas quelles heures de travail mériteraient une rallonge.

Par défaut, un espace arrêté et inactif est supprimé après trente jours. Une reconnexion remet le compteur à zéro ; la période recommence après l’arrêt. Le réglage personnel peut aller de zéro à trente jours. À zéro, l’arrêt, y compris celui provoqué par l’inactivité, entraîne la suppression. Ce choix retire donc aussi le confort du retour dans un environnement intact.

Certains espaces personnels peuvent être conservés jusqu’à une suppression manuelle, avec la consommation de stockage correspondante. Cette option n’est pas disponible pour les espaces de l’organisation soumis à sa politique de conservation. Les exceptions méritent d’être identifiées avant de transformer « trente jours » en prétendu plafond universel.

Sortir par une branche

GitHub propose une exportation des modifications vers une branche, sans démarrer l’espace. Elle peut être précieuse quand une limite de dépenses empêche de reprendre l’environnement. Encore faut-il regarder ce que l’on emporte : l’export porte sur la branche actuellement extraite, pas sur toutes les branches présentes. Des fichiers de plus de 100 MiB bloquent l’opération de poussée correspondante.

L’issue commerciale se joue dans cette vérification très peu spectaculaire. L’équipe doit retrouver les bonnes modifications dans le dépôt de destination, traiter ce qui existe ailleurs et savoir reconstruire l’environnement dont elle se sépare. Une exportation réussie d’une branche n’est pas un déménagement complet de l’atelier.

La réduction du parc demande donc deux gestes distincts : régler les conditions des futurs espaces et décider du sort de ceux qui existent. Les confondre permet de présenter rapidement une économie. Les séparer permet de savoir si elle a réellement commencé.