GitHub: aus Services werden Webhooks

Für mich ziemlich überraschend (angekündigt ist das wohl schon seit Ewigkeiten) stellt GitHub die Benutzung von GitHub Services am 31.01.2019 ein. Ich habe die bisher fleißig genutzt, um jeden meiner Commits nach Twitter zu spiegeln (also nur Spielerei) und um die gbsplay-Mailingliste mit Commit-Mails zu füttern (das ist durchaus sinnvoll).

Ersetzt werden die Services durch Webhooks: Statt dass wie bisher GitHub auf die Events reagiert und Dinge tut, bekommt man jetzt per HTTP ein Event vor die Füße geworfen und kann das selber verarbeiten. Ich würde gerne weiterhin auf die Events reagieren (vielleicht kann ich dann in Zukunft auch neu angelegte Bugs direkt in die Mailingliste doppeln?) und einen Webserver habe ich auch. Was kann also schiefgehen?

Wie geht dem?

Was ein Webhook ist, das kann ich mir technisch vorstellen: Da wird per POST irgendwo was abgekippt, wenn etwas passiert ist.

Die Events und deren Daten hat GitHub schön dokumentiert.

Der Migrationsguide beschreibt die Umstellung für GitHub Apps, OAuth Apps und GitHub Service provider. Das bin ich ja alles nicht. Ein wenn Du ein kleiner User bist, clonst Du Dir folgendes Repository und änderst die Config gibt es leider nicht.

Also was tun? Ich muss mir wohl eine eigene Anwendung dafür schreiben, kann ja so wild nicht sein.

Anwendungsdesign V1

Was brauche ich?

• Webhooks empfangen (irgendwas, was im Webserver läuft oder selber einen Port aufmacht)
• JSON-Events parsen (ja, das geht)
• Mails verschicken (billig)
• Twitternachrichten verschicken (auch das hab ich schon gemacht)

Insgesamt eher ein Integrations- als ein Entwicklungsprojekt.

Ganz klar: Das schreibe ich in Java, dann bin ich schön typsicher. Kein größeres Projekt mehr in irgendwelchen Skriptsprachen! Kurz gegoogelt: Es gibt Twitter4J, da muss ich das schon mal nicht selber erfinden.

Insgesamt wird das aber ein etwas umfangreicheres Projekt und dann Testfälle und alles und so viel Zeit habe ich auch nicht… Das kriege ich bis Ende Januar nicht hin!

Und ein schönes (persistentes) Message-Queuing-System brauche ich auch, entweder selber schreiben oder irgendwas aussuchen (was effektiv genauso lange dauert, da ich mich mit sowas nicht auskenne).

Außerdem riecht das ganze nach einem dicken Monolithen und dann läuft erstmal gar nichts bis alles fertig ist und außerdem werde ich wochenlang irgendwelche Details refactoren bis der Arzt kommt.

Das klappt nicht.

Anwendungsdesign V2

Denken wir doch mal agiler und überlegen uns Schrittgrößen, wo ich an einem Abend, an dem ich mal zwei Stunden hacken kann, einen sinnvollen Teil komplett fertig programmieren kann:

• Das JSON empfangen und wegschreiben – klingt nicht wild.
• Ein Skript, das die Daten sieht und guckt, was damit zu tun ist (moment, hab ich gerade Skript gesagt?).
• Für jeden Eventtyp (push, issue, …) ein Programm, das das Event verarbeitet.

Prima kleine Häppchen für Zwischendurch.

Und zum Persistieren und Kommunizieren nehme ich einfach Dateien (merke: ein Dateisystem ist auch eine Datenbank), dann kann ich lustig die Programmiersprache für jeden Teil wechseln.

Spoiler: Das war eine Gute Idee™ und so hat es auch funktioniert.

Anwendungsdesign V3

Es haben sich natürlich noch ein paar Änderungen ergeben (von „hey, das geht sorum besser“ bis zu „das Feature hätte ich jetzt aber auch noch gerne“), die finale Architektur sieht wie folgt aus – passenderweise werden das auch eigene Folgeartikel (ob ich das auch alles pünktlich bis Ende Januar zusammengeschrieben bekomme?):

1. technische Anbindung an den Webserver
2. JSON-Daten empfangen und in einer lokalen Queue persistieren
3. die Queue beobachten und die Events dispatchen
4. Perl-Hilfsbibliothek
5. Eventhandler für Commits
6. Eventhandler für Issues und Pull-Requests
7. Hilfsskripte und Betrieb
8. Bonus: Webhooks per API einrichten

Etwas untypisch für mich ist, dass das tatsächlich noch in keinem Code-Repository liegt. Irgendwo muss man ja schludern, wenn man schnell fertig werden will :-/

bisheriges Fazit

Läuft und tut, war überraschend schnell fertig, ist überraschend flexibel und bisher überraschend bugfrei!

Meine urspünglichen Ansätze von „Großprojekt, ich will Typsicherheit!“ sind restlos verflogen:

• Sowohl die Eingabedaten (JSON in Textform), die Kommunikation innerhalb meines Konstrukts (JSON in Textdateien, Dateinamen) als auch die Ausgabedaten (Emails, Tweets, Logdateien) sind reine Texte. Da tut es tatsächlich ein böses stringly typed system statt eines schönen strongly typed system.
• Jedes Einzelskript ist aktuell kleiner 100 Zeilen. Da blickt man auch ohne Typsystem und Compilerunterstützung durch.
• Für jedes Skript kann ich individuell gucken, welche Programmiersprache ich nehme: bisher Shell für die ganz einfachen Sachen und Perl, sobald ich etwas tiefer in der JSON-Struktur stochern muss.
• Die Skripte sind so kurz, dass ich jedes davon in kürzester Zeit nochmal komplett neu schreiben könnte. Hier könnte ich mal eine neue Programmiersprache oder sowas anhand einer sinnvollen Aufgabe in einer Produktionsumgebung ausprobieren :-)
• Da untereinander über Dateien kommuniziert wird, kann ich bei Fehlern oder zum Testen ganz einfach mit cat(1), cp(1), mv(1) und emacs(1) in das System eingreifen.

Die vielen kleinen austausch- und erweiterbaren Module haben richtig Spaß gemacht!

Und ganz nebenbei habe ich mich auch ein wenig mit systemd angefreundet.