Zusammenfassung

  • Die Aufbewahrungsfrist eines Codespace wird bei seiner Erstellung festgelegt. Ändert oder löscht eine Organisation später die Richtlinie, bleiben die bereits vergebenen Fristen bestehen.
  • Angehaltene Umgebungen verbrauchen weiterhin Speicher. Die automatische Löschung berücksichtigt nicht, ob Änderungen noch ins entfernte Repository übertragen werden müssen.

Die neue Sparregel ist beschlossen, der Screenshot liegt im Protokoll. Künftig sieben statt dreißig Tage Aufbewahrung: So lässt sich eine Kostenmaßnahme angenehm kurz erklären. Bei GitHub Codespaces braucht die Erklärung allerdings einen zweiten Satz. Die alten Umgebungen behalten ihre bisherigen Fristen.

Das Zahlenpaar ist ein Rechenbeispiel für eine Einstellung, kein beobachteter Kundenfall. Die offizielle Richtliniendokumentation legt den Mechanismus fest: Die Frist wird beim Erstellen vergeben. Eine spätere Änderung der Organisationsrichtlinie wirkt nicht auf bestehende Codespaces. Auch das Entfernen der Richtlinie ändert deren Fristen nicht.

Die Organisation hat damit ihre Eingangstür neu beschriftet. Wer schon drinnen sitzt, erhält dadurch keinen früheren Räumungstermin. Diese Unterscheidung schützt laufende Arbeitszusammenhänge und verlangt vom Kostenmanagement mehr als einen Besuch in den Einstellungen.

Angehalten ist noch immer abgestellt

Ein Codespace hält eine Entwicklungsumgebung in der Cloud bereit. Nach dem Anhalten lässt sie sich mit den gespeicherten Dateien wieder aufnehmen. Genau dieser Komfort beansprucht weiterhin eine Ressource.

GitHub trennt in der Beschreibung des Lebenszyklus zwischen Rechenverbrauch während des Betriebs und Speicherverbrauch, der nach dem Anhalten weiterläuft. Erst die Löschung beendet den weiteren Speicherverbrauch. Bereits im Monat angefallene Nutzung verschwindet dadurch nicht aus der Abrechnung. Das Schließen eines Browser-Tabs hält die entfernte Maschine zudem nicht automatisch an.

Eine Organisation kann folglich gleichzeitig eine strengere neue Richtlinie und einen umfangreichen alten Bestand haben. Dessen nächste Abgänge hängen von den jeweils vergebenen Fristen und der Nutzung ab. Der aktuelle Wert im Menü erklärt den Bestand nur teilweise.

Hinzu kommt der Kostenträger. Die Organisationsrichtlinie gilt für Codespaces, die von der Organisation bezahlt werden. Ein persönlich bezahlter Codespace fällt nicht allein deshalb darunter, weil sein Repository der Organisation gehört. Bei der Erstellung entscheidet die kürzeste der anwendbaren Fristen aus Organisations-, Repository- und persönlichen Einstellungen.

Für eine belastbare Bestandsaufnahme braucht es daher den tatsächlichen Zahler und die wirksame Frist jedes einzelnen Arbeitsraums. Die öffentlichen Unterlagen enthalten weder Kundeninventar noch zugeteilte Fristen, noch nicht übertragene Arbeit oder Rechnung; konkrete Einsparungen und Verluste lassen sich erst mit diesen Daten berechnen.

Der Löschtermin liest keinen Code

Wer eine Datei speichert, hat sie zunächst auf der virtuellen Maschine abgelegt. Damit die Arbeit im entfernten Repository liegt, müssen die Änderungen noch committed und gepusht werden. Zwischen beiden Zuständen kann genau das liegen, was das Team nicht verlieren möchte.

Die automatische Löschung findet auch dann statt, wenn Änderungen noch nicht gepusht wurden. Der Ablauf kennt die Frist. Den wirtschaftlichen Wert der letzten Arbeitsstunden kennt er nicht.

Standardmäßig wird eine angehaltene und ungenutzte Umgebung nach dreißig Tagen gelöscht. Eine erneute Verbindung setzt den Zähler zurück; nach dem nächsten Anhalten beginnt er erneut. Persönlich lässt sich eine Frist zwischen null und dreißig Tagen einstellen. Null bedeutet Löschung beim Anhalten, auch wenn dieses durch den Inaktivitätszeitraum ausgelöst wird.

Die kürzeste Einstellung hat damit einen Preis jenseits des Speichers: Sie nimmt dem Nutzer die Möglichkeit, später einfach in dieselbe erhaltene Umgebung zurückzukehren. Umgekehrt können bestimmte persönliche Codespaces bis zur manuellen Löschung aufbewahrt werden, mit entsprechendem Speicherverbrauch. Für organisationsverwaltete Codespaces unter einer Aufbewahrungsrichtlinie steht diese Ausnahme nicht zur Verfügung.

Das Erstellungsdatum allein verrät also nicht, welcher Arbeitsraum zuerst verschwindet. Eine alte, gelegentlich wieder aufgerufene Umgebung kann länger bleiben als eine neue mit kurzer Frist. Die vermeintlich einfache Bereinigung besteht aus mehreren Uhren.

Der Ausgang führt über eine bestimmte Branch

GitHub bietet einen Export von Änderungen in eine Branch, ohne den Codespace zu starten. Das kann helfen, wenn etwa ein Ausgabenlimit den Neustart verhindert. Exportiert wird jedoch nur die aktuell ausgecheckte Branch. Andere Branches werden nicht mitgenommen; Dateien über 100 MiB blockieren den betreffenden Push und damit den Export.

Eine betriebliche Übergabe muss deshalb den Inhalt am Ziel prüfen. Welche Änderungen liegen dort tatsächlich? Bleibt auf einer anderen Branch eigenständige Arbeit zurück? Lässt sich die Entwicklungsumgebung wiederherstellen? Eine erfolgreiche Branch-Übertragung hat einen konkreten Umfang. Die gesamte Werkbank kann größer sein.

Wer Kosten reduzieren will, muss diese Arbeit dem einzelnen Codespace zuordnen. Nach dem gesicherten Abtransport lässt sich entscheiden, ob die schnelle Wiederaufnahme weiterhin Speicher wert ist. Die neue Richtlinie regelt zukünftige Zugänge; die nachvollziehbare Entscheidung über vorhandene Umgebungen räumt den Bestand auf.