#forge

Radicle CI — eine Pipeline, die auf Patches reagiert

Permalink 4 min read Published:
 infrastructure  #radicle #ci #p2p #forge #cosign #supply-chain #zot #kubernetes #git
Der Code des Labs liegt in einer P2P-Forge, die CI aber noch nicht: Builds laufen post-merge auf einer externen .build.yml. Wie ein Radicle-CI-Broker das schließt — er hört auf die Patch-Events der eigenen Seed-Node, baut und signiert in-cluster und schreibt das Ergebnis zurück auf den Patch. Plus das eigentlich harte Problem: Vertrauen in einer Forge ohne Owner.
Stand: Design/Roadmap. Issue 7f834f9 : „Wire Radicle CI once the lab repo is published (patches already wired)." Die Seed-Node läuft in-cluster, der Patch-Workflow steht — der CI-Broker ist das letzte fehlende Stück. Dieser Beitrag beschreibt, wie er andocken soll.

In Von SourceHut zu Radicle ist der Lab-Code in eine Peer-to-Peer-Forge umgezogen: keine zentrale Instanz mehr, Patches und Issues leben als signierte Collaborative Objects (COBs), Flux deployt vom kanonischen main. Ein Faden blieb dort offen — und genau um den geht es hier: Radicle ist eine Forge, kein CI-System. Der Code liegt P2P, der Build aber noch nicht.

Radicle: Eine Forge, die niemandem gehört

Permalink 4 min read Modified: (UPDATED)
 infrastructure  #radicle #git #sourcehut #p2p #forge #open-source #ci
Was eine peer-to-peer-Git-Forge für die Open-Source-Welt bedeutet — und warum ich gerade all meine Repos von SourceHut zu Radicle umziehe

Git ist von Haus aus dezentral — aber die Art, wie wir damit zusammenarbeiten, ist es längst nicht. Pull Requests, Issues, Reviews: All das lebt auf zentralen Plattformen, die das Protokoll selbst gar nicht braucht. Radicle holt diese Kollaborationsschicht zurück ins dezentrale Modell, und genau deshalb ziehe ich gerade nicht nur mein Lab, sondern alle meine Repos dorthin um — und das sind einige, überwiegend die Quellen meiner Container-Images.