Was nach dem Hochladen einer Änderung passiert

Eine Änderung an ipe.rest erreicht die Besucher über einen kurzen Workflow auf GitHub. Er kopiert die Seite, prüft sie, veröffentlicht sie und sagt Suchmaschinen, was neu ist. Die meisten Läufe sind in unter 40 Sekunden fertig.

Der letzte Beitrag beschrieb, wie die Seiten gebaut werden. Dieser beginnt dort, wo jener endet: wenn eine Änderung den Branch main unseres Repositorys erreicht. Die Zahlen stammen vom 10. November 2026: aus der Workflow-Datei, aus einem lokalen Build der Seite und aus den letzten acht Läufen auf GitHub.

Kopieren

Die Seite besteht aus einfachen Dateien, also ist der erste Schritt ein Kopiervorgang. Der Workflow holt das Repository und kopiert alles außer dem, was Besucher nicht brauchen: die Skripte, die Tests, den Workflow selbst, Daten der Versionsverwaltung und alle Markdown-Dateien. Von den 586 Dateien im Repository gelangen 329 in den Seitenordner, etwa 10 MB.

Prüfen

Dann laufen sieben Tests gegen diesen Ordner, nicht gegen das Repository. Sie suchen die Dateien, die ein Besucher braucht, etwa die robots-Datei, die Sitemap, den Service Worker und die Startseiten; Ordner, die nicht dort sein dürfen, etwa scripts und tests; und die 404-Seite, die auf noindex stehen und zur Startseite verlinken muss. Ein Fehler stoppt den Workflow an dieser Stelle. Nichts wird veröffentlicht, und die bisherige Version bleibt online.

Veröffentlichen

Als Nächstes wird der Ordner hochgeladen und an GitHub Pages übergeben, das ihn ausliefert. Es läuft immer nur ein Deploy: Trifft eine neuere Änderung ein, während einer läuft, wird der ältere Lauf abgebrochen. Dazwischen liegt kein Server von uns und keine Datenbank. Ändert sich die Version des Service Workers, installiert der Browser eines Besuchers einen frischen Cache und löscht bei einem späteren Besuch die alten.

Mitteilen

Nach dem Veröffentlichen schickt der Workflow an IndexNow, ein Protokoll, das Bing, Naver, Yandex und andere Suchmaschinen akzeptieren, die Adressen der Seiten, deren Sitemap-Datum nach koreanischer Zeit heute ist. Der dafür nötige Schlüssel ist eine öffentliche Textdatei im Stammverzeichnis der Seite. Dieser Schritt darf fehlschlagen: Tut er das, gilt der Deploy trotzdem als Erfolg.

Wie es bisher lief

Von den letzten acht Läufen waren sieben erfolgreich und einer fehlgeschlagen; der nächste Lauf, 22 Sekunden später, war erfolgreich. Fünf der sieben erfolgreichen Läufe dauerten weniger als 40 Sekunden, der langsamste 2 Minuten 18 Sekunden. Wir haben vom Start eines Laufs bis zu seiner letzten Aktualisierung gemessen, die Zeiten sind also ungefähr zu verstehen.

Was ein grüner Lauf nicht sagt

Ein bestandener Lauf sagt, dass die Dateien angekommen sind und sieben Prüfungen bestanden wurden. Er sagt nicht, dass eine Seite auf einem kleinen Handybildschirm richtig aussieht, und IndexNow informiert Suchmaschinen nur; es verspricht nichts darüber, wann oder ob sie eine Seite aufnehmen.

ipe(); // copy, check, publish, tell

Der Workflow ist absichtlich kurz. Weniger Schritte lassen weniger Stellen, an denen eine ruhige Seite kaputtgehen kann.