Ein CI-Broker für Radicle, der wirklich baut — die Reise durch jede Wand
Vor zwei Wochen stand der Plan: ein CI-Broker, der auf Patch-Events meiner Radicle-Seed-Node hört, in-cluster baut und signiert. Das Diagramm war sauber. Die Realität war ein wochenlanger Kampf mit cib-Entrypoints, Flux, das meine Shell-Variablen auffraß, stale :latest-Tags, rootless buildah, das in Kubernetes prinzipiell nicht geht, und einem binfmt_misc-Handler, der auf Kernel 6.x immer wieder verschwand. Hier ist jede Wand, gegen die ich gelaufen bin — und wie der Broker am Ende doch baut.
In Radicle CI — eine Pipeline, die auf Patches reagiert habe ich den Plan beschrieben: Meine Seed-Node läuft in-cluster und führt einen Event-Stream — jede neue Patch-Ref, jedes COB-Update wird sichtbar. Ein CI-Broker abonniert diesen Stream, übersetzt ein Patch-Event in einen Build und schreibt das Ergebnis zurück auf den Patch. Sauberes Diagramm, klare Idee, ein offenes Trust-Problem, das ich für lösbar hielt.
Was dieser Beitrag erzählt, ist die Lücke zwischen dem Diagramm und einem grünen Häkchen. Sie war größer, als mir lieb war. Zwischen „der Broker ist deployt" und „der Broker baut wirklich ein signiertes Image" lagen rund zwei Dutzend Commits, die fast alle fix: heißen — und jeder davon steht für eine Wand, gegen die ich gelaufen bin. Das hier ist die ehrliche Version: kein Architektur-Pitch, sondern ein Reisebericht durch Entrypoints, die nicht stimmen, durch Flux, das meine Shell-Variablen frisst, durch rootless buildah, das in Kubernetes prinzipiell nicht funktioniert, und durch einen Kernel, der meinen QEMU-Handler immer wieder vergaß.