Buildah

Eigene CI für Radicle: vom Ref-Event zum überprüfbaren Release

Permalink 25 min read Published: 2026-10-09

Eine praktische Fortsetzung zum CI-Broker: eigene Radicle-Repositories bauen, Images und Helm-Charts veröffentlichen, mit Syft und Trivy prüfen und Releases mit überprüfbaren Digests beschreiben. Mit Konfigurationsbeispielen, den Gründen für cosign-legacy und den Grenzen des nativen Runners.

Wenn der erste Build durchläuft, funktioniert der grundlegende Ablauf einer eigenen CI. Für den verlässlichen Betrieb bleiben jedoch Fragen offen, die eine gehostete Forge oft bereits im Produkt beantwortet. Dazu gehören Ausführungsrechte, die Zuordnung von Images zu Commits und die Prüfung beider Architekturen. Dazu kommt die Freigabe eines Releases, bei der Git-Tag, Registry-Artefakt und Radicle-Veröffentlichung zusammenpassen müssen, obwohl sie getrennt entstehen.

Mein erster CI-Broker-Beitrag beschrieb die Probleme beim Aufbau und die Lösungen, die daraus entstanden sind. Diese Fortsetzung führt schrittweise durch die Einrichtung und richtet sich an Menschen, die Radicle bereits verwenden und ihre eigene CI betreiben möchten. Der Broker ist inzwischen bei v1.5.0 angekommen. Er unterstützt die gemeinsame Veröffentlichung und Signierung von Images und Charts, bringt Werkzeuge für SBOMs und Schwachstellenscans mit und verarbeitet Release-Ereignisse zuverlässiger.

Dafür muss niemand mein komplettes Lab nachbauen. Entscheidend ist der Weg vom replizierten Commit bis zu einem Artefakt, dessen Herkunft und Prüfergebnisse auch andere nachvollziehen können.

Ein CI-Broker für Radicle, der wirklich baut — die Reise durch jede Wand

Permalink 19 min read Modified: 2026-06-26 (UPDATED)

infrastructure #radicle #ci #buildah #binfmt #kubernetes #talos #flux #p2p #cosign #supply-chain

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. 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ß.