Zusammenfassung

  • GitHub rundet die Laufzeit jedes Jobs auf die nächste volle Minute auf. Wer alle Sekunden zuerst addiert und nur einmal rundet, übersieht die einzeln gekauften Mindestmengen.
  • Sechs vollständige Zehnsekundenjobs ergeben im Rechenbeispiel sechs Minuten, ein einzelner Sechzigsekundenjob eine. Beim aktuellen Standard-Linux-Runner mit zwei x64-Kernen entspricht das 0,036 gegenüber 0,006 US-Dollar Rechenwert.

Auf der Rechnung können sechs Minuten stehen, obwohl die addierten Joblaufzeiten nur eine ergeben. Die Erklärung steckt in den Grenzen zwischen den Jobs. GitHub Actions zählt jeden davon mit einer eigenen Uhr und rundet jede Uhr einzeln auf.

Die offizielle Runner-Preistabelle schreibt dieses Aufrunden je Job vor. Ein zehnsekündiger Auftrag bekommt eine Verpackung für sechzig Sekunden. Sechs kleine Aufträge bekommen sechs Verpackungen. Der Entwickler zeichnet eine Struktur; der Repository-Eigentümer kauft deren Einheiten.

Erst einzeln runden, dann addieren

Setzen wir ein privates Repository und denselben Standard-Linux-Runner mit zwei x64-Kernen voraus. Die aktuelle Tabelle nennt 0,006 US-Dollar pro Minute. Sechs vollständige Jobs mit jeweils exakt zehn Sekunden Laufzeit werden zu sechs Minuten, also 0,036 US-Dollar. Ein vollständiger Job mit exakt sechzig Sekunden wird zu einer Minute, also 0,006 US-Dollar.

Beide Varianten enthalten sechzig addierte Runner-Sekunden. Der Unterschied beträgt 0,03 US-Dollar berechneten Verbrauch. Diese bedingte Rechnung verwendet angenommene Joblaufzeiten und veröffentlichte Regeln. Eine tatsächliche Zusammenlegung kann Vorbereitung, Nacharbeit, Abhängigkeiten und Laufzeit verändern. Sechs zehnsekündige Befehle sind außerdem noch kein Nachweis für sechs vollständige Zehnsekundenjobs.

Der Käufer braucht deshalb die gemessene Ausführungszeit des gesamten Jobs. Die Ansicht der Joblaufzeit führt zur Laufzeit und den berechneten Minuten. Runner-Kategorie, geltender Preis und Verbrauchsabrechnung liefern die weiteren Teile der Rechnung.

Eine Sekunde mit auffällig hoher Kaufkraft

Bei einer vollständigen Joblaufzeit von 61 Sekunden berechnet GitHub zwei Minuten, bei genau sechzig Sekunden eine. In diesem Vergleich entfällt durch die Kürzung um eine Sekunde der angefangene zweite Minutenblock. Eine Verkürzung von elf auf zehn Sekunden bleibt dagegen in beiden Fällen bei einer Minute.

Die Preisfunktion hat Stufen. Gesparte Zeit und gespartes Geld verlaufen deshalb nicht gleichmäßig. Eine kleine Verbesserung an der Minutengrenze kann mehr Menge sparen als eine große Beschleunigung eines ohnehin kurzen Jobs. Eine reine Bestenliste der eingesparten Sekunden würde die falschen Gewinner küren.

Daneben steht die Wartezeit auf das Ergebnis. Parallele Jobs können diese Wartezeit verringern, während die aufsummierte Runner-Laufzeit eine andere Größe bleibt. Darüber liegt die Summe der einzelnen Aufrundungen. Frühes Ergebnis, wenig Maschinenzeit und wenig berechnete Minuten sind drei Ziele, zwischen denen eine Organisation handelt.

Zunächst bezahlt der enthaltene Rechenwert

Die aktuelle Abrechnungsbeschreibung drückt den im Plan enthaltenen Rechenumfang als Geldwert aus. Berechtigte Runner-Nutzung sowie Rechenleistung und Arbeitsspeicher von Cloud-Sandboxen können aus demselben Wert schöpfen. Zwischen berechtigten Nutzungsarten besteht keine Priorität. Der Wert wird zu Beginn des Abrechnungszyklus erneuert; nach seinem Verbrauch fallen zusätzliche Gebühren an.

Die 0,036 US-Dollar im Beispiel können also zunächst enthaltenen Wert verbrauchen. Erst jenseits dieses Umfangs werden sie zur zusätzlichen Zahlung. Vorher nehmen sie Kapazität ein, die andere berechtigte Arbeit hätte nutzen können. Auf den ersten Kreditkartenzuschlag zu warten heißt, einen Teil der Kaufentscheidung zu spät zu betrachten.

Standard-Runner von GitHub sind in öffentlichen Repositories unabhängig davon kostenlos. Größere Runner sind auch dort kostenpflichtig. Unsere Zahlen gelten für die festgelegte private Standardkonfiguration. Ein Preisvergleich braucht diese Kategorie ebenso wie den Minutenwert.

Manche Grenzen sind ihr Geld wert

Die Einführung in Actions unterscheidet Workflows, Jobs und Schritte. Schritte eines Jobs laufen auf demselben Runner; Jobs besitzen eigene Ausführungsumgebungen. Ohne Abhängigkeiten laufen Jobs standardmäßig parallel. Aktuelle Funktionen erlauben auch ausgewählte gleichzeitige Schritte innerhalb eines Jobs. Parallelität verlangt somit nicht in jedem Fall zusätzliche Jobgrenzen.

Verschiedene Betriebssystemtests, getrennte Umgebungen, klarere Fehlertrennung und frühe Rückmeldungen können solche Grenzen rechtfertigen. Auf einem gemeinsamen Runner lassen sich zwischen Schritten Daten teilen. Notwendige Tests zu streichen oder Aufgaben mit unterschiedlichen Vertrauens- und Berechtigungsgrenzen nur wegen der Rundung zusammenzulegen, würde das gekaufte Ergebnis verändern.

Für eine reale Einsparung fehlen die tatsächlichen vollständigen Laufzeiten, Runner-Typen, gleichwertigen Prüfergebnisse, Wartezeiten, Wiederholungen und die Verwendung des enthaltenen Werts. Die Rechnung belastet den Repository-Eigentümer. Wer Jobgrenzen festlegt, bestimmt damit auch die aufgerundete Rechenmenge, die bei diesem Eigentümer verbucht wird. Eine Planung allein mit der Laufzeitsumme unterschlägt die einzelnen Rundungsaufschläge. Ein kurzer Job darf sinnvoll sein. Eine volle Minute sollte erklären können, welchen Vorteil ihre Grenze kauft.