GitHub liefert abgelaufene Actions-Artefakte nicht mehr über die REST-API aus
Victoria Shinder2 Min. LesezeitGitHub hat am 24. September geändert, wie ein abgelaufenes Actions-Artefakt von außen aussieht. Bisher blieb ein Artefakt, dessen Aufbewahrungsfrist verstrichen war, in der Zusammenfassung des Workflow-Laufs stehen und trug dort die Markierung "Expired" - obwohl die Daten längst aus dem Speicher entfernt waren. Diese Zeile ist verschwunden, und mit ihr die entsprechenden Einträge aus zwei REST-Endpunkten: dem, der die Artefakte eines Repositorys auflistet, und dem, der ein einzelnes Artefakt abruft. Begründet wird das mit Verwirrung bei der Abrechnung: die Markierung ließ offen, ob für Dateien weiterhin gezahlt wird, die es nicht mehr gibt.
Zwei Dinge bleiben ausdrücklich unverändert. Die Aufbewahrungseinstellungen verhalten sich genau wie vorher, die Abrechnung ebenfalls - geändert hat sich die Anzeige und die Aufzählung, nicht der Lebenszyklus. Und die Information ist nicht verloren: welche Artefakte ein Lauf erzeugt hat, steht weiterhin in den Logs dieses Laufs.
Was das bedeutet
Der API-Teil ist der, der still etwas zerbrechen kann. Jedes Skript, das die Artefaktliste eines Repositorys durchlief und das Gefundene zählte, verglich oder archivierte, erhält für ältere Läufe nun eine kürzere Liste - ohne Fehler und ohne Hinweis, dass sich die Form der Antwort geändert hat. Wer das Vorhandensein eines abgelaufenen, aber gelisteten Artefakts als Marker benutzt hat - "dieser Lauf wurde aufgeräumt" gegen "dieser Lauf wurde nie verarbeitet" -, hat diese Unterscheidung gerade verloren, und der Fehlerfall ist ein Job, der beschließt, es sei nichts zu tun.
Die Abrechnungsbegründung sollte man wörtlich nehmen und nicht als Beschönigung. Ein Oberflächenelement, das ein nicht existierendes Objekt zeigt, ist ein echter Mangel in einer Ansicht, mit der Leute ihre Rechnung nachvollziehen - es zu entfernen ist richtig. Es zeigt aber die allgemeine Kosten dieser Art von Fehler: dieselbe Zeile erledigte zwei Aufgaben, eine schlechte (sie suggerierte belegten Speicher) und eine nützliche (sie dokumentierte Historie), und gemeint war nur die schlechte. Wer sich auf die zweite verlassen hat, braucht jetzt die Lauf-Logs - ein schlechterer Index als eine API, weil sie pro Lauf statt pro Repository existieren und nach eigenem Zeitplan verfallen.